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ABSTRACT 


Strategic  information  systems  (IS)  planning  aligns  an  organization’s  information 
systems  with  its  critical  strategic  goals  and  supporting  mission-specific  functions.  This 
thesis  demonstrates  a  structured  approach  to  strategic  IS  planning  and  provides  a  guide  for 
developing  an  information  systems  architecture  to  support  the  organizational  goals  of  the 
Office  of  Naval  Intelligence  (ONI).  By  first  examining  established  information  systems 
planning  practices,  architectural  design  methodologies.  Department  of  Defense  (DoD) 
guidelines,  and  published  ONI  organizational  objectives,  this  thesis  guides  the  reader 
through  the  decision-making  process  involved  in  strategic  IS  planning.  The  methodology 
is  structured  on  guidance  provided  by  the  DoD’s  Technical  Architecture  Framework  for 
Information  Management  (TAFIM)  Standards-Based  Architecture  (SBA)  Planning  Guide. 
This  thesis  demonstrates  the  validity  of  using  the  structured  architectural  approach, 
presented  by  the  TAFIM  and  other  strategic  IS  planning  concepts,  in  concert  with 
intelligence-specific  IS  planning  guidance  to  systematically  address  the  issues,  problems, 
and  critical  decisions  faced  by  organizations  attempting  the  strategic  IS  planning  process. 
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1.  INTRODUCTION 


A.  PURPOSE  OF  THESIS 

The  purpose  of  this  thesis  is  to  demonstrate  a  structured  approach  to  strategic 
information  systems  (IS)  planning.  This  thesis  provides  mid-  and  top-level  managers  at  the 
Office  of  Naval  Intelligence  (ONI)  with  a  guide  for  developing  an  information  systems 
strategy  and  architecture  that  supports  organizational  goals  outlined  in  the  ONI  Strategic 
Plan.  By  examining  established  information  systems  planning  practices,  architectural 
design  methodologies.  Department  of  Defense  (DoD)  guidelines,  and  published  ONI 
organizational  objectives,  this  thesis  provides  a  guide  through  the  decision-making  process 
involved  in  strategic  IS  planning.  This  thesis  presents  a  framework  for  developing  a 
strategically  aligned  systems  architecture  that  is  specifically  applicable  to  current  systems 
development  efforts  at  ONI. 

At  the  enterprise  level,  the  objective  of  this  thesis  is  to  link  the  strategic-planning 
vision  and  direction  of  ONI  with  a  supporting  information  systems  plan.  Strategic  IS 
planning  practices  provide  the  concepts  and  practical  guidance  for  establishing  the  link 
between  the  fundamental  business  functions  of  an  organization  and  its  supporting 
information  systems.  Strategic  IS  planning  must  be  an  integral  part  of  an  organization’s 
general  planning  process  performed  within  a  strategic  framework.  “Strategic  advantages 
are  gained  when  the  organization  is  able  to  distinguish  itself  through  lower  costs,  better 
products  or  services,  or  unique  capabilities.”  [Ref.  l:p.  9]  These  advantages  can  be 
exploited  by  ONI  or  any  organization  that  successfully  maps  its  general  strategic  vision  to  a 
shared  vision  of  the  proper  strategic  use  of  information  technology.  “Few  organizations 
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can  claim  to  have  a  widely  shared  vision  of  how  they  might  best  prosper  in  the  Information 
Age.”  [Ref.  l;pp.  262-263] 

At  the  work-group  level,  the  objective  of  this  thesis  is  to  bridge  the  gap  of  individual 
understanding  between  those  focused  on  the  organizational  mission  and  functional  tasks 
(the  users)  with  those  charged  with  designing  and  providing  supporting  information 
resources.  It  attempts  to  provide  the  “big  picture”  to  those  who  often  feel  the  immediate 
impact  of  seemingly  continual  information  systems  modifications  and  technology  advances. 

Many  common  shortcomings  of  information  systems— such  as 
technical  elegance  at  the  expense  of  relevance,  hardware  efficiency  at  the 
expense  of  flexibility  . . .  stem  in  part  from  the  difficulties  some  technical 
managers  have  in  seeing  problems  from  the  perspective  of  the  user  and  the 
needs  of  the  business.  This  can  feed  on  itself,  setting  up  a  barrier  to 
communications  and  cooperation  between  users  and  the  technical  staff. 

[Ref  l:p.  14] 

Hopefully,  this  thesis  can  serve  as  a  vehicle  for  communication,  coordination,  and 
increased  understanding  among  involved  parties. 

Though  this  thesis  is  written  in  response  to  research  requirements  that  parallel 
systems  development  efforts  at  ONI,  significant  portions  of  this  thesis  are  applicable  to  any 
large-scale  organization,  government  or  commercial,  with  a  critical  dependence  on 
automated  information  systems.  As  with  most  strategic  IS  planning  approaches,  the 
purpose  is  to  link  business  and  information  strategies  to  facilitate  and  enhance  the  most 
critical  business  functions.  This  research  involved  literature  reviews  and  case  studies 
associated  with  private  business  organizations.  It  examines  several  established  strategic 
planning  practices  and  demonstrates  methodologies  currently  in  practice  within  DoD.  In 
the  process,  it  presents  a  systematic  method  for  resolving  issues  common  to  organizations 
with  large  information  systems  investments. 
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B.  BACKGROUND 


This  thesis  is  being  written  for  the  Office  of  Naval  Intelligence  (ONI)  located  in 
Suitland,  Maryland.  ONI  is  responsible  for  the  collection,  production,  and  dissemination 
of  maritime  intelligence  information  in  support  of  the  Department  of  the  Navy  (DoN),  joint 
and  Naval  operating  forces  and  commands,  the  defense  research  and  development  (R&D) 
community,  the  Department  of  Defense  (DoD),  and  the  national  command  authorities  and 
agencies.  In  support  of  its  mission,  ONI  manages  a  large  array  of  automated  information 
systems  that  include  both  older  technology  mainfirame  computer  systems  as  well  as  a  more 
modem  workstation  environment.  The  computer  systems  support  large  databases  and 
intelligence-specific  applications  supporting  mission  areas  including  scientific  and  technical 
intelligence  and  operational  intelligence.  An  extensive  communications  architecture 
supports  requirements  to  collect  data,  interface  with  other  command  and  intelligence 
organizations  and  systems,  and  disseminate  information  to  intelligence  consumers. 

Current  DoD  policy  directs  efforts  for  achieving  compatibility  and  interoperability 
among  Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  systems. 
Recent  efforts  focus  on  creation  of  joint  intelligence  and  communications  architectures 
across  the  Unified  Commands,  the  individual  Services,  and  DoD  agencies.  Further  policy 
direction  from  the  Director  of  Naval  Intelligence  (DNl)  has  consistently  been  in  accordance 
with  Department  of  Defense  Intelligence  Information  System  (DODIIS)  and  Common 
Operating  Environment  (COE)  objectives.  Additionally,  the  ONI  Strategic  Plan  provides 
the  vision  and  goals  to  ensure  that  Naval  Maritime  Intelligence  resources  are  available  to  all 
users  who  need  that  information. 

Given  that  the  genesis  of  the  new  Global  Command  and  Control  System  (GCCS)  is 
the  Joint  Maritime  Command  Information  System  (JMCIS),  the  basis  now  exists  to 
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implement  within  ONI  a  truly  interoperable,  open  systems,  C4I  architecture  that  will 
support  national,  theater,  and  tactical  users.  Therefore,  as  a  matter  of  policy,  all  ONI 
systems  development  is  being  accomplished  within  the  JMCIS  architecture  and  its 
established  systems  development  procedures.  Over  the  last  decade,  ONI  has  sponsored 
several  intelligence  systems  development  efforts  with  the  Naval  Command,  Control,  & 
Ocean  Surveillance  Center  (NCCOSC),  Research,  Development,  Tests,  &  Evaluation 
Division  (NRaD).  Current  efforts  focus  on  design  and  implementation  of  a  common 
architecture  and  stmcture  that  can  accommodate  unique  ONI  analytical  requirements  within 
the  JMCIS  framework.  To  ensure  these  unique  requirements  and  organizational  goals  are 
carefully  addressed,  a  structured  strategic  IS  planning  process  is  required.  This  thesis 
specifically  addresses  this  requirement.  [Ref.  2] 

C.  SCOPE  AND  METHODOLOGY 

The  main  thrust  of  this  thesis  will  be  applying  established  principles  of  information 
systems  planning  to  the  architecture  development  effort  at  ONI.  Specifically,  the  heart  of 
the  effort  will  include  the  development  of  a  draft  target  architecture  that  wDl  focus  on 
mission  critical  systems  at  ONI,  primarily  those  supporting  intelligence  production  within 
the  Intelligence  Directorate  (ONl-2).  Additionally,  it  will  present  a  framework  for  making 
critical  migration  path  decisions  that  can  be  generically  applied. 

The  methodology  is  structured  on  guidance  provided  by  the  DoD’s  Technical 
Architecture  Framework  for  Information  Management  (TAFIM)  Standards-Based 
Architecture  (SBA)  Planning  methodology.  This  thesis  is  not  intended  to  thoroughly 
address  or  demonstrate  all  aspects  of  the  planning  process  described  in  the  TAFIM.  The 
SBA  Planning  process  calls  for  a  much  more  exhaustive  approach  to  be  conducted  by  an 
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organizationally  internal  Architecture  Working  Group  and  Architecture  Steering  Cominittee 
with  a  trained  facilitator.  When  conducted  on  an  intensive  basis  with  dedicated  personnel 
and  other  required  resources,  the  SBA  planning  process  will  typically  require  over  one  year 
to  complete.  That  level  of  effort  and  coordination  is  clearly  beyond  the  scope  of  this  thesis. 
However,  it  is  the  intent  of  this  thesis  to  demonstrate  the  validity  of  using  the  stmctured 
architectural  approach  presented  by  the  TAFIM  and  other  strategic  IS  planning  concepts  in 
concert  with  intelligence- specific  IS  planning  guidance,  provided  through  the  DoD 
Intelligence  Information  System  (DODIIS)  program,  to  systematically  address  the  issues, 
problems,  and  critical  decisions  faced  by  organizations  attempting  the  strategic  IS  planning 
process. 

In  addition  to  an  external  literature  review,  thesis  research  included  numerous 
personal  interviews  with  mid-  and  top-level  managers  at  ONI  within  both  the  Intelligence 
Directorate  (ONI-2)  and  the  Systems  Directorate  (ONl-7),  as  well  as  intelligence  analysts 
(system  users)  within  ONI-2.  Two  visits  were  made  to  ONI  between  December  1993  and 
June  1994.  Additional  interviews  and  coordination  was  performed  with  systems  engineers 
at  NRaD  in  San  Diego  during  a  February  1994  visit. 

This  research  is  intended,  as  much  as  possible,  to  present  an  internal  focus  with  direct 
application  to  current  systems  development  efforts  at  ONI.  In  a  sense,  this  thesis  is 
intended  to  be  used  as  a  companion  guide  in  conjunction  with  research  recently  completed 
and  presented  to  ONI  in  the  thesis  entitled  “Downsizing  Information  Systems:  Framing  the 
Issues  for  The  Office  of  Naval  Intelligence  (ONI)”  by  Lieutenant  Peter  M.  Hutson  in  March 
1994.  His  complementary  research  offers  a  more  external  perspective  of  relevant 
downsizing  issues  framed  specifically  for  ONI.  With  an  understanding  of  those  issues  as  a 
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backdrop,  the  internal  planning  methods  then  offered  by  this  thesis  provides  decision¬ 
makers  at  ONI  with  a  broad  perspective  of  the  strategic  IS  planning  process. 

D.  OUTLINE  OF  CHAPTERS 

1.  Chapter  II.  Strategic  Information  Systems  Planning 

In  this  chapter,  the  concepts  of  strategic  information  systems  (IS)  planning  are 
first  presented  in  the  broader  context  of  strategic  business  planning.  Specifically,  the 
analytical  techniques  of  Critical  Success  Factors  and  Pressure  Point  Analysis  are  reviewed. 
These  common  concepts  are  narrowed  to  the  IS  field  with  an  explanation  of  the 
architectural  approach  to  strategic  IS  planning.  Continuing  toward  a  more  structured 
approach,  the  specific  methodologies  offered  by  DoD’s  Technical  Architecture  Framework 
for  Information  Management  (TAFEM)  and  DoD’s  Intelligence  Information  System 
(DODnS)  guidelines  are  examined.  This  chapter  prepares  the  reader  with  a  broad 
understanding  of  strategic  IS  planning  and  a  specific  understanding  of  the  methodologies 
that  structure  the  development  of  ONI’s  systems  architecture. 

2.  Chapter  III.  Initiation  and  Architecture  Framework 

In  this  chapter,  the  structured  methodology  offered  by  the  architectural  approach 
to  strategic  IS  planning  is  initiated.  The  chapter  presents  the  issues  that  initiate  the  planning 
process  within  an  architecture  framework.  ONI’s  strategic  planning  documents  and 
mission  statements  are  examined.  Strategic  IS  initiatives  that  directly  impact  ONI  systems 
development  are  also  reviewed.  Central  to  this  chapter  is  the  development  of  initial  IT 
Principles  for  ONI  that  will  guide  the  systems  development  and  architectural  planning 
efforts.  Finally,  key  issues  that  will  impact  the  overall  architecture  process  are  presented  to 
set  the  stage  for  further  phases  in  the  planning  and  development  process. 
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3.  Chapter  IV.  Baseline  Characterization 

This  chapter  presents  a  high-level  basehne  characterization  of  the  IS  environment 
currently  supporting  the  critical  mission  /  business  functions  at  ONI.  The  baseline 
environment  is  presented  from  four  separate  views:  work  organization  view,  information 
view,  apphcation  view,  and  technology  view.  Applications,  systems,  and  databases  that 
directly  support  ONI  intelligence  analysts  are  presented. 

4.  Chapter  V.  The  Target  Architecture 

This  chapter  presents  a  draft  target  architecture  to  guide  systems  development 
and  evolution  at  ONI.  This  chapter  specifically  addresses  the  Joint  Maritime  Command 
Information  System  (JMCIS)  architecture.  A  thorough  understanding  of  the  JMCIS 
architecture  is  essential  to  guide  the  architecture  development  efforts  at  ONI.  Application  of 
the  JMCIS  architecture  concepts  to  ONI  system  requirements  are  first  presented  in  the 
chapter. 

5.  Chapter  VI.  Opportunity  Identification 

This  chapter  builds  on  the  basic  understanding  of  the  target  architecture  by 
identifying  the  opportunities  presented  by  JMCIS.  The  opportunities  are  presented  with 
regard  to  the  strategic  goals  and  IT  principles  of  ONI.  Opportunities  are  identified  which, 
once  implemented,  can  demonstrate  the  value  of  the  architecture  and  provide  immediate 
benefits  to  the  organization. 

6.  Chapter  VII.  Migration  Analysis 

This  chapter  presents  a  framework  to  assist  decision-makers  in  the  process  of 
analyzing  a  migration  path  toward  the  target  architecture  environment.  The  chapter  first 
defines  many  of  the  terms  required  to  properly  discuss  and  further  analyze  a  migration 
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plan.  With  the  terminology  as  a  back  drop,  this  chapter  then  specifically  addresses  some 
concerns  regarding  the  migration  plan  for  ONI  systems.  Finally,  this  chapter  offers  a 
suggested  framework  to  properly  evaluate  and  select  a  migration  plan.  A  generic  decision 
framework  is  presented  that  is  a  functionally-oriented,  capability-based  approach.  It  is 
intended  to  be  a  useful,  step-by-step  method  that  produces  valuable  information  about  the 
migration  path  selected.  The  framework  is  presented  to  offer  decision  makers  a  structured 
approach  to  evaluating  migrations  options. 
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11.  STRATEGIC  INFORMATION  SYSTEMS  (IS)  PLANNING 

A.  STRATEGIC  PLANNING  AND  ANALYSIS  FOR  IS 
1.  Definition 

Strategic  planning  is  defined  in  the  literature  in  many  ways.  It  takes  on  a  variety 
of  meanings  depending  on  the  context  or  business  environment  in  which  it  is  used.  In  the 
commercial  sector,  one  might  define  strategic  planning  as  “planning  in  response  to 
corporate  business  initiative.”  [Ref.  3:p.  2]  Military  planners  define  strategic  planning  as 
the  large-scale,  long-range  utilization  and  deployment  of  the  nation’s  forces  to  ensure 
national  security  objectives.  In  the  broadest  sense,  however,  planning  is  simply  “deciding 
in  advance  what  is  to  be  done.”  And  strategic  planning  is  making  those  advance  decisions 
with  concern  for  the  fundamental  purpose  and  direction  of  the  entire  organization.  [Ref. 
4:p.  108] 

Strategic  information  systems  (IS)  planning  is  a  form  of  strategic  planning 
intended  to  align  an  organization’s  information  systems  with  it’s  critical  strategic  goals  and 
supporting  mission  specific  functions.  “The  objective  of  strategic  information  systems 
planning  is  to  define  the  explicit  connection  between  an  organization's  business  plan  and  its 
systems  plan  to  provide  better  support  of  the  organization's  goals  and  objectives  and  closer 
management  control  of  critical  information  systems.”  [Ref  3:p.  2]  The  basic  purpose  is  to 
link  the  business  and  information  strategies.  Establishing  a  link  between  fundamental 
business  needs  and  the  supporting  information  systems  requires  an  explicit  understanding 
of  those  needs.  The  consensus  of  many  companies  having  strategic  IS  planning  activities 
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is  that  planning,  set  in  a  strategic  framework,  will  allow  decisions  to  be  made  today  which 
will  better  prepare  them  for  the  future.  Strategic  IS  planning  must  therefore  be  an  integral 
part  of  an  organization’s  general  planning  process  and  be  performed  within  this  strategic- 
framework.  [Ref.  3:p.  9] 

2.  Elements  of  Strategic  IS  Planning 

The  concept  of  strategic  IS  planning  is  demonstrated  in  the  process  of 
systematically  thinking  through  a  business  situation,  considering  both  internal  and  external 
forces  that  may  impact  the  business,  anticipating  the  changes  that  information  technology 
will  effect  on  the  business,  and  developing  a  series  of  options,  or  alternative  objectives, 
from  which  management  can  select  a  course  of  action.  Business  situations  are  described  in 
terms  of  issues,  which  are  unresolved  management  concerns.  The  process  of  thinking 
through  these  issues  is  called  analysis.  A  course  of  action  may  then  be  chosen  from  the 
alternative  objectives  resulting  in  an  implementation  or  action  plans.  [Ref.  3:p.  2] 

Issues  and  objectives  are  the  key  elements  of  strategic  IS  planning.  The  purpose 
of  strategic  IS  planning  is  to  help  resolve  the  organization’s  business  issues  and  attain  the 
desired  objectives  by  setting  IS  objectives  and  accomplishing  them.  It  helps  to  resolve  the 
issues  by  the  selection  of  certain  options  from  among  various  possibilities  that  have  been 
analyzed  while  considering  the  business  factors  involved.  Strategic  IS  planning  involves  a 
disciplined  thinking  process  resulting  in  a  structured  communication  of  ideas.  Through 
strategic  IS  planning,  .strategic  business  issues  are  translated  into  specific  IS  action  plans. 
[Ref.  3;pp.  4-11] 
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3.  The  Strategic  IS  Planning  Process 


The  process  of  strategic  IS  planning  is  procedurally  described  throughout 
literature.  Wading  through  all  the  advice  on  strategic  planning  for  IS  can  be  difficult. 

There  are  many  differing  opinions  and  resultant  frameworks  to  choose  from.  However, 
they  all  sinoilarly  argue  that  an  organization’s  primary  concern  should  be  to  integrate  the 
strategic  IS  planning  process  with  the  general  strategic  planning  process.  This  section 
presents  a  high-level  view  of  the  strategic  IS  planning  process  that  is  common  to  most 
frameworks. 

The  first  step  common  to  most  strategic  IS  planning  processes  is  a  thorough 
analysis  and  understanding  of  the  organization’s  general  strategic  goals  as  laid  out  in  a 
strategic  plan.  IS  objectives  are  set  only  after  strategic  analyses  are  conducted.  The  IS 
planning  process  starts  with  business  objectives  and  not  IS  objectives.  The  “strategy” 
referred  to  should  always  be  the  strategy  of  the  organization  for  which  the  information 
resources  support,  not  the  strategy  of  the  information  services  group  itself.  This  initial  step 
typically  includes  a  review  of  the  organization’s  business  plans  in  order  to  clarify  corporate 
objectives  and  identify  critical  mission  /  business  functions.  Strategic  IS  planning  must 
begin  with  the  development  of  a  framework  of  business  issues  and  objectives  to  properly 
align  the  IS  activities  with  the  business  activities.  From  this  framework,  essential 
information  needs  can  be  established  and  future  requirements  identified.  [Ref.  3:p.  29] 

Also  among  the  first  steps  common  to  IS  planning  is  an  internal  analysis  to 
evaluate  how  information  resources  are  currently  supporting  the  critical  business  functions 
of  the  organization.  Characterizing  the  information  systems  and  technologies  currently 


installed  provides  a  basis  on  which  to  begin  the  IS  planning  process.  This  step  also  serves 
to  identify  weaknesses  in  the  current  systems  architecture  that  need  to  be  closely  examined 
from  a  strategic  perspective  during  the  IS  planning  process. 

The  next  step  in  strategic  IS  planning  is  bom  out  of  the  first  two.  With  an 
understanding  of  the  critical  business  functions  and  a  characterization  of  the  currently 
available  information  resources,  the  next  step  in  the  planning  process  should  develop  and 
describe  a  goal  or  target  IS  environment  that  will  support  the  strategic  information 
requirements  of  the  organization.  A  strategically  designed  IS  infrastructure  is  developed 
through  a  shared  vision  among  both  technical  and  operational  personnel  of  how 
information  technology  can  support  the  user. 

Lack  of  a  shared  vision  inhibits  the  strategic  use  of  information 
technology.  The  technology  has  the  potential  to  bring  about  profound  changes, 
but  success  will  be  elusive  without  some  common  understanding  of  what  the 
organization  wants  to  achieve  and  how  [information  systems]  can  contribute. 

[Ref.  l:pp.  262-263] 

With  an  understanding  of  the  current  state  of  IS  within  the  organization  and  a 
vision  of  where  the  organization  wants  to  go,  identification  of  available  opportunities  that 
allow  attainment  of  the  target  IS  environment  is  required.  Various  IS  opportunities  that 
fulfill  the  requirements  of  the  target  environment  are  recognized  as  potential  alternatives 
during  this  step  in  the  planning  process.  This  step  involves  the  generation  of  feasible 
alternative  courses  of  action  with  an  analysis  to  determine  what  impact  the  alternatives  may 
produce.  Determining  the  most  strategically  beneficial  option  is  the  goal  of  this  phase  in  the 
planning  process. 

Opportunity  identification  and  selection  is  generally  followed  in  the  strategic  IS 
planning  process  by  a  plan  to  implement  the  selected  alternative.  This  step  typically 


12 


involves  a  planned  transition  phase  in  which  the  current  IS  environment  is  “migrated” 
toward  the  target  environment  using  the  selected  opportunity.  This  final  phase  is  often 
referred  to  as  operational  IS  planning  where  strategies  to  handle  specific  IS  projects  and 
activities  are  devised  and  included  in  the  operational  planning  cycle.  Strategic  IS  planning 
is  in  direct  response  to  corporate  business  initiatives.  It  is  usually  concerned  with  specific 
IS  projects  in  support  of  specific  business  plans  of  high  priority.  In  this  manner,  strategic 
business  issues  are  translated  into  specific  IS  action  plans  through  the  strategic  IS  planning 
process.  [Ref  3:p.  6] 

The  process  of  strategic  IS  planning  is  described  in  many  different  ways  with  the 
basic  steps  arranged  in  various  orders.  The  process  is  inherently  flexible  and  changeable 
because,  by  its  nature,  strategic  planning  is  concerned  with  special  situations  that  have 
differing  time  demands  and  a  wide  range  of  management  interest  and  urgency.  While  the 
overall  process  must  be  flexible  enough  to  accommodate  new  technologies,  each  part  in  the 
process  is  itself  well  stmctured.  It  is  the  structured  approach  of  each  step  in  the  process 
that  ensures  the  critical  alignment  between  the  strategic  business  plan  and  the  specific  IS 
action  plans.  [Ref.  3:pp.  12-26] 

4.  Strategic  IS  Analysis 

Strategic  planning  often  requires  diverse  planning  techniques  and  data  analysis 
methods  at  different  phases  of  the  planning  process.  Analytical  methods  are  required  to 
resolve  complex  issues  into  settled,  or  final,  objectives.  In  general,  strategic  planning  is 
the  method  for  settling  issues,  resolving  unanswered  questions,  and  refining  the  results  of 
strategic  analysis  into  a  statement  of  objectives.  Several  methods  may  be  required  to 
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perform  this  analysis,  including  business  plans  analysis,  environmental  analysis, 
forecasting,  trend  analysis,  internal  analysis,  risk  analysis,  contingency  analysis,  and 
economic  analysis.  At  the  end  of  a  successful  strategic  analysis,  objectives  are  set  and  a 
strategic  plan  is  prepared.  Decision-oriented  planning  is  facilitated  through  the  use  of 
detailed  analysis  in  the  strategic  planning  process.  [Ref.  3:pp.  19-20] 

Several  analysis  techniques  have  been  introduced  for  use  in  strategic  IS 
planning.  For  example,  the  use  of  Critical  Success  Factors  (CSF)  in  planning  was  first 
proposed  by  Dr.  John  Rockhart  of  the  Center  for  Information  Systems  Research  at  MIT. 
There  have  since  been  numerous  articles  published  on  the  subject  and  many  successful  uses 
of  the  approach.  The  methodology  requires  management  to  define  the  organization’s 
Critical  Success  Factors,  limiting  the  number  of  factors  to  “the  relatively  few  things  that  an 
organization  judges  that  it  must  do  well  to  thrive.”  [Ref.  l:p.  290]  Developing  a  set  of 
Critical  Success  Factors  has  become  a  popular  way  of  extracting  top  management’s  key 
concerns,  giving  uniform  direction  to  the  planning  process,  and  stating  general  goals  while 
the  outcome  is  still  technically  ill-defined.  The  high-level  approach  of  this  technique  is 
appropriate  for  strategic-level  IS  planning. 

Another  high-level  analytical  technique  is  called  Strategic  Pressure  Point 
Analysis  (PPA).  This  technique  also  provides  a  way  of  gathering  and  presenting 
information  that  focuses  on  issues  of  particular  interest  to  management,  rather  than  on  the 
specific  technical  problems.  The  “pressure  points”  are  considered  those  key  external 
factors  producing  the  most  pressures  on  the  current  status  of  the  IS  infrastructure.  One 
apparent  strength  of  PPA  can  been  seen  in  the  model  provided  for  organizing  and  clearly 
presenting  the  information  to  help  decision  makers  view  the  various  pressures  influencing 
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the  decision  process.  Figure  1  is  an  example  of  a  business-oriented  PPA  model  depicting 
the  various  pressure  points  considered. 


Pressure  Point  Analysis  provides  a  simplistically  clear  analytical  approach  to 
planning  embodied  in  four  fundamental  questions  concerning  the  role  of  IS  in  an 
organization: 

•  Where  are  we? 

•  Why  should  we  change? 

•  What  could  we  do? 

•  What  should  we  do? 

The  search  for  and  display  of  answers  to  these  questions  comprises  the  sum  and  substance 
of  Strategic  Pressure  Point  Analysis.  Answering  these  fundamental  questions  incorporates 
the  basic  steps  common  to  all  strategic  IS  planning  processes.  The  steps  can  be 
summarized  as  producing  a  profile  of  existing  IS  functions  (Where  are  we?);  identifying 
the  issues  demanding  a  solution  (Why  should  we  change?);  listing  strategic  alternatives 
(What  could  we  do?);  and  recommending  a  course  of  action  (What  should  we  do?).  [Ref. 
3:p.  69] 
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Figure  1:  Strategic  Pressure  Point  Analysis  Chart  [Ref.  3:p.  68] 
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5.  Outcome  of  Strategic  IS  Planning 


The  strategic  IS  planning  process  provides  an  opportunity  for  an  organization  to 
consider  explicitly  how  it  should  exploit  the  capabilities  of  information  technology.  If  done 
successfully,  this  process  should  produce  a  plan  that  provides  the  following: 

•  A  description  of  a  desired  future  IS  capability  required  to  support  the  strategic 
needs  of  the  organization; 

•  Guidance  for  current  actions  aimed  at  achieving  the  plan; 

•  A  framework  and  focus  for  organized  problem  solving; 

•  A  means  for  communication  and  coordination  among  involved  parties. 

[Ref.  l:pp.  259-260] 

Typically,  various  documents  are  produced  during  the  planning  process.  The 
documents  that  come  from  all  types  of  planning  are  created  to  define  objectives,  analyze 
alternatives,  and  describe  the  directions  which  should  be  taken.  The  documents  specifically 
serve  to  communicate  the  strategic  IS  plan.  Documents  describe  the  systems  architecture, 
the  strategic  alternatives,  the  options  considered,  and  the  equipment  and  software 
strategies.  Together  they  form  the  strategic  IS  plan. 

A  useful  strategic  IS  plan  must  provide  guidance  for  making  relatively  short-term 
decisions  on  such  matters  as  the  allocation  of  resources  and  the  selection  among  technical 
alternatives.  A  plan  that  has  no  bearing  on  these  decisions  is  too  future-oriented  or  too 
irrelevant  to  contribute  much.  The  strategic  IS  plan  must  also  take  a  longer-term  view, 
because  it  takes  a  series  of  purposeful  actions  to  put  into  place  the  kind  of  IS  infrastructure 
that  can  support  the  organization’s  strategic  objectives.  Stated  differently,  the  objective  of 
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strategic  IS  planning  is  to  arrive  at  near-term  decisions  that  coincide  with  the  long-term 
direction  of  the  organization.  [Ref.  l:p.  260] 

B.  ARCHITECTURAL  INFORMATION  SYSTEMS  (IS) 
PLANNING 

Recent  IS  planning  strategies  focus  on  structured  methods  to  guide  the  planning  and 
analysis  process.  While  previous  strategic  IS  planning  practices  were  derived  from 
generally  accepted  business  planning  techniques,  strategic  IS  planning  has  required  a  more 
structured  approach  to  ensure  a  successful  alignment  of  the  business  and  IS  plans. 

Today’s  IS  planning  techniques  have  an  apparent  systems  engineering  influence.  Systems 
analysis  techniques  have  blended  with  more  traditional  organizational  analysis  to  constitute 
the  modem  strategic  IS  planning  process.  These  techniques  include  information  modeling, 
business  process  re-engineering,  and  systems  architecture.  The  merger  of  the  behavioral 
science  approach  to  organizational  planning  with  the  systems  engineering  approach  to 
systems  design  has  resulted  in  the  architectural  approach  to  strategic  IS  planning.  “For  the 
1990s  through  the  2000s,  information  systems  architecture  and  the  architectural  approach 
as  the  main  methodology  for  strategic  systems  planning  are  recognized  as  the  key  issues  for 
IS.”  [Ref.  5:p.  102] 

1.  Definition 

The  term  architecture,  long  used  to  describe  aspects  of  building  design,  has  been 
applied  to  technical  systems  for  about  a  generation.  A  technical  systems  architecture 
defines  components,  interfaces,  services,  and  the  framework  in  which  they  are 
incorporated.  An  IS  architecture  is  a  set  of  components  and  a  specification  of  how  these 
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components  are  connected  to  meet  the  overall  requirements  of  an  information  system. 
Components  provide  either  information  processing  or  communications  services. 
Architecture  is  not  necessarily  a  diagram  of  the  components  or  a  set  of  diagrams.  “Rather, 
it  is  a  set  of  company  policies  and  rules,  that  when  followed,  are  expected  to  lead  to  the 
information  systems  environment  that  is  desired.”  [Ref.  6:p.  182] 

An  analogy  can  be  useful  in  understanding  what  an  architecture  is  and  why  it  is 
important.  An  architecture  t5q)ically  allows  designers  (architects)  to  lay  out  the  plans  for  a 
project  in  terms  that  builders  or  developers  can  understand  and  use  them  to  guide  the 
construction  process.  Like  the  building  architecture,  the  plans  include  provisions  for  the 
various  services  to  be  offered  in  the  building,  such  as  electrical  power,  plumbing, 
communications  wiring,  stairwells,  elevators,  etc.  They  must  also  provide  the  overall 
design  of  the  building.  An  architectural  plan  must  also  consider  zoning  laws,  regulations 
and  standards  for  building  usage.  It  must  also  consider  the  entrances  and  exits,  layout  of 
the  equipment  which  may  be  housed  in  the  building,  and  the  type  of  construction  material 
needed  to  meet  the  planned  usage  requirements  of  each  area  of  the  building.  The 
architecture  must  ensure  that  components  of  the  building  fit  together  to  meet  the  needs  of 
the  prospective  tenants  and  the  surrounding  environment.  It  must  also  have  the  ability  to 
evolve  with  the  changes  over  time  such  as  the  need  for  expansion  or  for  alternative  uses. 
[Ref.  7:Vol.  4,pp.  1-2  to  1-3] 

The  architecture  does  not,  however,  concern  itself  with  details  such  as  the 
specific  color  of  carpet  a  given  tenant  may  want,  or  exactly  how  each  person’s  desk  will  be 
oriented.  Rather,  the  architecture  concerns  itself  with  providing  a  flexible,  adaptable 
infrastructure  to  meet  these  varying  needs  without  tearing  down  the  building  and  starting 
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over.  This  is  accomplished  by  adhering  to  solid  principles  of  architecture  design,  by 
developing  a  set  of  blueprints  (or  frameworks)  for  the  building’s  appearance  and  layout, 
and  by  setting  some  basic  standards  for  the  construction  teams  to  follow  as  they  implement 
the  plans.  The  framework  serve  as  a  starting  point  to  begin  construction.  [Ref.  7:Vol.  3,p. 
5] 

Similar  to  the  building  architecture,  an  IS  architecture  serves  as  the  underlying 
framework  that  defines  and  describes  the  IS  requirements  of  an  organization  and  its 
primary  functions.  Meeting  these  requirements  will  allow  the  organization  to  attain  its 
business  objectives.  The  IS  architecture  provides  the  structure  for  information, 
applications,  and  the  technological  means.  It  describes  the  groupings  of  components,  their 
interrelationships,  the  principles  and  guidelines  governing  their  design,  and  their  evolution 
over  time. 

The  bottom  line  on  architectures,  for  buildings  and  for  [IS],  is  providing  a 
minimum,  but  rigorous,  set  of  guidelines  and  standards  which  will  allow  the 
building  (or  information  systems)  to  be  developed  in  a  way  which  will  allow  the 
most  flexibility  for  the  tenants  (or  system  users)  while  constraining  the  detailed 
designs  enough  to  ensure  that  the  desired  style  and  characteristics  of  the 
building  (or  the  computing  environment)  are  maintained  over  time.  [Ref.  7:Vol. 

4,  p.  1-5] 

2.  Principles  of  Systems  Architecture 

There  is  a  direct  analogy  in  the  principles  of  IS  architecture  for  each  of  the  more 
general  architecture  points  discussed  above.  The  architectural  principles  for  a  building 
define  the  overall  style  of  the  building  and  its  general  characteristics.  With  these 
architectural  principles,  one  gets  a  fairly  good  idea  of  the  kind  of  building  and  some  of  the 
constraints  which  will  be  placed  on  the  construction.  In  IS  architecture,  the  principles 
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provide  a  similar  mechanism  for  defining  the  kind  of  information  systems  that  will  result. 
The  IT  architectural  principles  are  the  foundation  for  decision  making  about  the  general 
style  of  computing  and  technology  usage  for  the  organization. 

An  example  IT  principle  might  be: 

To  the  extent  possible,  similar  business  functions  will  be  supported  by 
common  systems  which  will  support  all  physical  locations.  These  systems  will 
be  run  locally,  within  each  plant  location,  but  will  be  maintained  and  updated 
from  a  centr^  location.  The  systems  will  be  developed  within  an  industry 
standard  environment  and  will  be  interconnected  for  data  sharing  via  a  series  of 
interconnected  telecommunications  networks,  which  will  communicate  using 
industry  standard  protocols.  Access  to  all  systems  will  be  via  intelligent 
workstations  connected  to  the  network  and  using  a  set  of  common  user  interface 
standards.  [Ref.  7:Vol.  4,  p.  1-4] 

This  principle  would  then  be  used  to  guide  the  development  of  models  and  associated 
specifications  for  the  way  the  organization  will  use  IS.  With  this  principle,  the  style  of 
computing  and  communications  is  defined  with  enough  depth  to  allow  appropriate  detailed 
design  work  to  begin  and  developers  selected. 

As  the  constmction  begins,  some  specific  decisions  will  have  to  be  made  about 
vendors  as  well  as  the  details  of  construction  for  specific  user  needs.  In  the  construction 
planning  phase,  the  architecture  still  forms  the  framework  for  decision  making,  but  more 
detailed  plans  wUl  have  to  be  developed  for  each  user’s  specific  requirements.  Here,  the 
cost  of  materials,  durability  requirements,  specific  equipment  locations,  and  office  layout 
must  be  considered.  A  detailed  design  must  be  developed  with  specific  cost  estimates,  time 
to  complete,  vendors  to  be  used,  etc.  This  goes  beyond  architectural  planning  but  must 
remain  consistent  with  the  architectural  principles  and  blueprints  for  the  overall  building. 
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3.  Elements  of  Architectural  IS  Planning 


With  the  building  architecture  analogy  as  a  backdrop,  architectural  IS  planning 
can  be  defined  “as  the  art  and  science  of  transforming  a  functional  need  for  computer-based 
systems  into  a  planned  and  organized  framework  which  supports  integration  and  enables 
systems  design  and  delivery.”  [Ref.  7:Vol.  4,p.  1-5]  The  architectural  IS  planning  process 
requires  the  definition  of  components  or  “building  blocks”  and  ways  to  describe  the 
relationship  among  components.  The  architecture  provides  the  link  between  identifying  a 
strategic  opportunity  to  apply  computer  solutions  and  choosing  the  best  available  solution. 

In  order  to  link  the  strategic  functional  requirements  of  an  organization  to  the 
supporting  IS  infrastructure,  the  IS  architecture  must  reflect  four  different  views  of  the 
organization.  These  four  views  are; 

♦  Work  organization  view.  The  work  organization  view  describes  the  major 
operations  that  are  performed  by  work  groups  in  support  of  mission  /  business 
functions.  This  view  should  address  how  the  planned  system  will  impact  work 
activities,  change  skill  requirements,  affect  functional  operating  locations,  and 
eliminate  or  reduce  manual  support. 

*  Information  view.  The  information  view  describes  the  critical  information  used  by 
the  organization  and  the  relationships  among  collections  of  information  (databases). 
This  view  should  address  the  information  /  databases  that  are  required  to  operate  the 
function,  and  the  format  and  volume  of  information  involved. 

•  Application  function  view.  The  application  view  shows  which  functions  of  the 
organization  can  be  supported  by  IS  applications.  It  provides  a  high-level  description 
of  these  applications  and  descries  logical  dependencies  and  relationships  among 
application  areas.  This  view  should  describe  what  types  of  application  functions  are 
required  to  support  the  organization  and  associated  users,  how  functions  will  be 
grouped  and  interfaced,  and  what  usage  levels  are  anticipated.  This  view  defines  the 
scope  and  interfaces  of  applications  and  provides  the  basis  for  detailed  design. 
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•  Technology  view.  The  technology  view  is  used  to  describe  the  enabling 
infrastructure.  To  provide  the  necessary  linkage  to  the  work  organization, 
information,  and  applications  architecture  views,  the  technology  view  can  further  be 
described  in  terms  of  generic  "building  blocks".  This  view  should  describe  what 
types  of  technology  services  are  required  and  how  should  they  be  distributed  to 
various  types  of  technology  platforms,  how  these  services  and  platforms  will  be 
networked,  and  what  standards  and  guidelines  are  required  to  support  integration. 
[Ref.  7:Vol.  4] 

The  work  organization  view  forms  the  critical  foundation  on  which  the  strategic 
IS  planning  process  can  begin.  The  application  and  information  views  are  used  in  tandem 
to  define  the  targeted  applications  and  information  that  will  support  the  organization. 
Together  they  drive  the  requirements  for  technology.  It  is  important  that  standards-based 
architectures  reflect  a  balance  of  these  four  views  of  their  relationship. 

4.  Goals  of  an  IS  Architecture 

Given  an  understanding  of  the  purpose  and  elements  of  architectural  IS 
planning,  an  IS  architecture  must  address  three  goals: 

•  Provide  a  means  of  cost  effectively  organizing  information  and  its  technologies  to 
support  the  organization’s  objectives; 

•  Improve  the  effectiveness  of  IS  in  delivering  new  capabilities  to  the  organization; 

•  Facilitate  continual  evolution  of  the  IS  infrastructure  and  solutions  over  time.  [Ref. 
7:Vol.  4,p.  1-10] 

Similar  to  other  strategic  IS  planning  techniques,  the  common  questions  addressed  by  the 
architectural  IS  planning  process  are: 

•  How  can  we  define  an  IS  architecture  which  meets  the  functional  vision  of  the 
organization? 

•  How  do  we  get  there  from  here? 
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C.  DOD’s  TECHNICAL  ARCHITECTURE  FRAMEWORK  FOR 
INFORMATION  MANAGEMENT  (TAFIM) 

1.  Overview 

The  Defense  Information  Systems  Agency  (DISA)  Center  for  Architecture  began 
publishing  a  multiple  volume  of  systems  architecture  development  guidelines  in  November 
1993.  These  documents  comprise  the  DoD  Technical  Architecture  Framework  for 
Information  Management  (TAFEM)  series.  The  purpose  of  TAFIM  is  to  provide  “an 
enterprise-level  guide  for  developing  technical  architectures  that  satisfy  specific  functional 
requirements.”  [Ref.  7:Vol.  l,p.  3]  The  TAFIM  is  not  intended  to  provide  a  specific- 
systems  architecture.  Rather,  it  provides  standards  and  design  concepts  that  can  be  used  to 
guide  the  development  of  technical  architectures  that  meet  specific  mission  requirements. 
The  TAFEM  provides  system  architects  and  designers  with  “a  basis  for  developing  a 
common  target  architecture  to  which  systems  can  migrate,  evolve,  and  interoperate.”  [Ref 
7:Vol.  l,p.  3] 

Like  other  strategic  level  planning  methodologies,  TAFIM  is  independent  of  the 
technical  details  regarding  mission-specific  applications  and  their  associated  data.  The 
specific  architectures  for  specific  missions  and  functions  will  be  developed  using  the 
standard  architecture  guidance  and  development  methodologies  provided  by  the  TAFIM. 
Although  high-level  in  nature,  the  TAFIM  approach  assumes  that  all  information  systems 
must  interoperate  at  some  time.  It  is  intended  that  through  the  widespread  use  of  a  standard 
methodology  such  as  the  TAFIM  provides,  interoperability  among  the  various  systems  will 
increase,  providing  users  with  improved  services  needed  to  achieve  common  functional 
objectives.  Proper  application  of  the  TAFIM  is  intended  to: 
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•  Promote  integration,  interoperability,  modularity,  and  flexibility; 

•  Guide  acquisition  and  reuse;  and 

•  Speed  delivery  of  information  technology  and  lower  its  costs. 

[Ref.  7:Vol.  l,pp.  3-4] 

The  TAFIM  defines  an  information  system  to  include  support  and  mission- 
oriented  applications,  computing  platforms,  and  communications  networks.  The  current 
DoD  IS  infrastructure  consists  largely  of  stovepipe,  single-purpose  systems  that  are  costly 
to  maintain.  These  systems  reflect  many  varied  approaches  to  migrate  toward  open 
systems  with  each  one  progressing  on  its  own  path  with  limited  attention  to 
interoperability.  In  the  absence  of  DoD-wide  systems  architecmre  guidance,  various  DoD 
organizations  and  agencies  have  developed  a  wide  range  of  architectures  to  manage  and 
control  their  IS  infrastructures.  Reference  models,  information  architectures, 
communications  architectures,  mission  architectures,  and  various  other  architectures  are 
now  used  to  manage  the  design  and  development  of  information  systems  within  DoD.  The 
TAFIM  was  developed  to  provide  a  single  IS  architecture  framework  to  integrate  these 
various  efforts  and  promote  common  systems  design,  acquisition,  and  reuse  principles 
throughout  DoD.  The  TAFIM  provides  a  DoD-wide  framework  to  manage  multiple  IS 
architecture  initiatives.  [Ref  7:Vol.  l,pp.  1-3] 

The  TAFIM  provides  a  set  of  volumes  to  guide  the  evolution  of  the  DoD's  IS 
architecture.  Version  2.0  of  the  TAFIM  Volumes  are  listed  below: 

•  Volume  1:  Overview. 

•  Volume  2:  Technical  Reference  Model  -  provides  the  conceptual  model  for 

information  system  services  and  their  interfaces. 
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•  Volume  3:  Architecture  Concepts  and  Design  Guidance  -  provides  concepts  and 
guidance  needed  to  support  the  development  of  technical  architectures  in  the  DoD. 

•  Volume  4:  Implementation  Manual  -  provides  a  standards-based  architecture 
planning  methodology  to  help  architects,  technical  integrators,  and  developers  plan 
and  build  information  systems  that  meet  mission,  functional,  and  application  area 
requirements.  The  methodology  provides  a  translation  of  functional  requirements  to 
the  selection  of  services,  standards,  components,  configurations,  their  phasing,  and 
the  acquisition  of  products  that  implement  them.[Ref.  7:Vol.l,p.  9] 

•  Volume  5:  Support  Plan  -  provides  guidance  on  how  to  use  the  TAFIM  in  the 
acquisition  of  IT  and  IM  products. 

•  Volume  6:  DoD  Goal  Security  Architecture  -  provides  security  requirements 
commonly  found  in  DoD  organizations  with  regard  to  missions  and  mission  threats. 
(Unpublished) 

•  Volume?:  Standards  Profile  and  Implementation  Guidance  -  provides  DoD  profile 
of  standards.  (Unpublished) 

•  Volume  8:  DoD  HCI  Style  Guide.  (Unpublished) 

[Ref.  7:Vol.  l,pp.  9-10] 

2.  Architectural  Guidance 

The  TAFIM  Volume  4  provides  a  Standards-Based  Architecture  (SBA)  Planning 
Guide  which  defines  a  common  framework  for  strategic  and  architectural  IS  planning 
among  all  levels  of  DoD.  The  TAFIM  Volume  4  is  intended  to  serve  as  a  key  element  of 
the  DoD’s  Corporate  Information  Management  (CIM)  initiatives  (to  be  further  discussed  in 
Chapter  HI).  It  serves  as  the  DoD-wide  strategic  IS  planning  guidance  for  the 
implementation  of  a  computing  and  communications  architecture  that  will  support 
portability,  scalability,  and  interoperability  of  applications.  The  CIM  initiatives  are 
reaffirmed  by  Deputy  Secretary  of  Defense  William  J.  Perry’s  policy  memorandum  of  13 
October  1993  entitled  “Accelerated  Implementation  of  Migration  Systems,  Data  Standards, 
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and  Process  Improvement”  It  calls  for  all  DoD  components  to  begin  migration  from 
legacy  to  target  systems  in  such  a  way  “that  migrate  the  system  toward  an  open  system 
environment  and  a  standards-based  architecture  defined  by  the  DoD  Technical  Architecture 
Framework  for  Information  Management  (TAFIM).”  [Ref.  7:Vol.  4,p.  1] 

3.  TAFIM  Methodology 

The  TAFIM  SBA  Planning  methodology  was  developed  to  assist  in  planning  IS 
architectures  within  a  functional  unit  or  department  within  the  DoD.  The  approach  is  also 
intended  to  be  useful  when  applied  at  a  lower  or  sub-department  level  providing  a  more 
detailed  view  of  the  architecture.  The  SBA  planning  process,  like  other  strategic  IS 
planning  methodologies  presented,  provides  a  mechanism  for  translating  the  mission 
critical  business  functions  of  an  organization  into  specific  IS  actions  which  are  derived 
through  the  use  and  implementation  of  the  entire  TAFIM  SBA  planning  process.  Figure  2 
represents  the  standards-based  architecture  planning  and  implementation  cycle  outlined  in 
the  TAFIM  Volume  4.  Similar  to  other  strategic  IS  planning  processes,  the  SBA  planning 
process  consists  of  seven  distinct,  but  interdependent,  phases.  Each  phase  produces 
specific  documents  as  deliverables  which  then  guide  the  subsequent  phase(s).  The  phases 
are  briefly  described  below: 

a.  Phase  One:  Initiation  and  Architecture  Framework 

This  phase  in  the  architectural  planning  process  is  direction-setting  in 
nature.  The  methodology  begins  by  initiating  the  process  within  the  host  organization. 
This  orientation  phase  involves  reviewing  (or  in  some  cases  developing)  a  set  of  strategic 
objectives  for  the  organization.  The  strategic  business  plan  is  reviewed  (or  built)  during 
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this  phase  to  establish  a  understanding  of  the  organization’s  strategic  vision.  A  set  of  IS 
architecture  principles  is  developed  to  establish  what  are  believed  to  be  good  architecture 
practices  for  the  organization.  [Ref.  7:Vol.4,p.  5] 


Figure  2:  The  TAFIM  Standards-Based  Architecture  (SBA) 
Planning  Process  [Ref.  7:Vol.  4,p.  4] 
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b.  Phase  Two:  Baseline  Characterization 


The  purpose  of  this  phase  to  determine  the  organization’s  current  IS 
environment.  It  is  used  to  establish  a  baseline,  or  starting  point,  for  architecture 
development.  The  baseline  characterization  provides  a  useful  means  for  organizing  and 
presenting  the  current  IS  status.  It  results  in  a  “picture”  of  the  existing  architecture  along 
four  key  dimensions,  or  views:  work,  information,  applications,  and  technology.  The 
term  “characterization”  is  used  because  the  data  gathering  and  analysis  are  not  exhaustive. 

It  is  not  necessary,  nor  is  it  desirable,  to  expend  the  time  and  effort  to  document  every 
detail  of  the  current  architecture.  Only  enough  detail  is  gathered  to  allow  informed 
decisions  to  be  made  with  regard  to  the  desired  target  architecture.  [Ref.  7:Vol.  4,p.  5] 

c.  Phase  Three:  Target  Architecture 

Target  architecture  development  is  the  heart  of  the  SBA  planning  process. 
The  target  architecture  specifies  the  new  IS  environment  and  highlights  the  key 
opportunities  for  improvement  over  the  baseline.  The  goal  of  this  phase  is  to  define  a  target 
architecture  that  can  be  used  to  support  and  thus  achieve  the  strategic  vision  of  the 
organization.  The  architecture  that  is  actually  implemented  will  likely  be  a  blend  of  the 
baseline  and  the  target  with  architectural  principles  as  the  foundation. 

d.  Phase  Four:  Opportunity  Identification 

This  phase  moves  the  architecture  out  of  the  conceptual  world  into  one 
where  the  practical  realities  govern  implementation.  In  this  step,  short-term  opportunities 
are  identified  which,  once  implemented,  can  demonstrate  the  value  of  the  target  architecture 
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and  provide  some  immediate  benefits  to  the  organization.  In  addition,  IS  projects  that  are 

necessary  to  achieve  the  target  architecture  are  identified  and  described  in  some  detail. 

e.  Phase  Five:  Migration  Options 

This  phase  links  the  reality  of  the  present  IS  environment  with  the 
desirability  of  the  target  architecture  by  establishing  steps  that  represent  practical  migration 
stages.  IS  projects  recognized  in  the  previous  step  as  opportunities  are  analyzed  with  best 
alternatives  identified.  The  objective  of  this  phase  is  to  develop  a  prioritized  set  of  project 
initiatives  which,  when  completed,  will  move  the  organization  from  the  current  state  to  the 
target  architecture.  [Ref.  7:Vol.  4,p.  6] 

/.  Phase  Six:  Implementation  Planning 

This  phase  results  in  a  detailed  implementation  plan  for  the  first  steps  of  the 
migration  effort.  The  plan  describes  the  first  actionable  projects  that  establish  the  basis  for 
each  successive  phase  of  the  target  architecture  implementation.  Milestones  are  established 
and  resource  requirements  defined.  [Ref.  7:Vol.  4,p.  7] 

g.  Phase  Seven:  SBA  Administration 

This  phase  is  intended  to  keep  the  architecture  current  and  meaningful  by 
continuously  improving  it.  It  reflects  the  need  to  modify  architecture  decisions  in  response 
to  unforeseen  changes  in  business  directions  or  advances  in  technology,  making 
adjustments  as  required.  This  phase  is  an  ongoing  process  intended  to  measure  and 
monitor  project  problems  and  architecture  compliance.  [Ref.  7;Vol.  4,p.  7] 
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4.  Resource  Requirements  and  Critical  Success  Factors 

The  SBA  planning  process  presented  by  the  TAFIM  offers  an  architectural 
approach  to  strategic  IS  planning.  It  has  many  similarities  to  strategic  IS  planning 
techniques  previously  discussed.  The  TAFIM  guidelines  provide  suggestions  for 
individual  organizations  to  tailor  the  SBA  Planning  requirements  to  best  fit  local 
resourcing,  size,  and  timing  constraints. 

Critical  to  the  success  of  this  planning  process  is  the  adoption  of  a  resourcing 
strategy  supported  at  the  highest  levels  of  the  organization.  The  SBA  Planning  process 
requires  an  Architecture  Working  Group  (AWG)  to  be  formed.  This  core  team  should 
consist  of  four  to  six  mid-level  managers  and  IT  personnel  from  the  functional  areas.  This 
team  will  develop  the  overall  project  plan  and  facilitate  the  SBA  process.  Key  players  must 
be  involved.  Additionally,  the  process  requires  formation  of  an  Architecture  Steering 
Committee  (ASC).  This  group  should  also  consist  of  a  mix  of  IT  and  functional  area 
experts  that  can  provide  expertise  and  guidance  to  the  project. 
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TABLE  1:  SBA  PLANNING  PROCESS  CRITICAL  SUCCESS  FACTORS 


SUCCESS  FACTOR 

DESCRIPTION 

Business  driven 

Use  the  architecture  process  to  reinforce  key  operational  Jind 
business  drivers. 

Participative  process 

Involve  teams  of  architects,  planners,  and  managers  directly  in  the 
creation  of  deliverables  to  establish  corporate  “buy-in.” 

Fast  paced 

Set  schedules  such  that  deliverables  arrive  within  weeks,  not 
months.  Show  early  results. 

Presumptive  resolution 

Do  not  get  bogged  down  if  facts  or  information  tire  not  avtiilable. 

Be  presumptive,  make  the  best  guess,  tind  document  tcssumptions. 

Architecture,  not  design 

Avoid  too  much  detail.  Focus  on  architecture  decisions  tind  save 
some  creative  work  for  the  designers  to  follow. 

Minimum  set 

Do  not  set  out  to  establish  standards  for  everything  in  sight.  Focus 
on  those  where  key  infrastructure  is  involved. 

Key  deliverables 

It  is  more  important  to  produce  results  which  everyone  can  abide  by 
than  to  follow  specific  processes  or  methods.  Use  the  framework 
but  be  creative  and  experimental  with  methods  using  suindiud  DoD 
tools  and  techniques. 

Open,  non-secretive 

Do  not  hide  the  team  away  and  stamp  everything  “confidentitil!” 

Invite  participation  and  circulate  drafts  for  review  tind  discussion. 

Ongoing  process,  not  event 

This  is  not  intended  to  produce  a  shelf  document.  Create  ongoing 
processes  for  updating  and  reviewing  are  critical. 

[Ref.  7:Vol.  4,p.  8] 


The  SBA  planning  process  is  organized  around  the  seven  phases  described. 
Ideally,  when  conducted  on  an  intensive  basis,  these  phases  will  require  approximately  one 
year  to  complete.  The  internal  organization  of  the  AWG  and  ASC,  coupled  with  the  time 
requirements,  obviously  calls  for  a  strong  commitment  and  support  at  the  executive  level  of 
the  organization.  Additionally,  the  process  calls  for  a  trained  group  facilitator.  Group 


facilitation  skills,  interview  skills,  general  functional  area  knowledge,  IT  knowledge,  and 
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project  management  skills  should  all  be  considered  required  staffing  skills  for  the  AWG 
and  ASC.  As  an  final  overview  of  the  TAFTM  methodology,  Table  1  presents  a  list  of  the 
associated  critical  success  factors  for  the  seven  phases  of  the  SBA  Planning  process. 

D.  DOD  INTELLIGENCE  INFORMATION  SYSTEM  (DODIIS) 
1.  Overview 

The  Department  of  Defense  (DoD)  Intelligence  Information  System  (DODIIS)  is 
a  national  program  comprising  “the  aggregate  of  personnel,  procedures,  equipment, 
computer  programs,  and  supporting  communications  of  the  Department  of  Defense  which 
support  the  timely  and  comprehensive  preparation  and  presentation  of  intelligence  ...  to 
military  commanders  and  national-level  decision  makers.”  [Ref.  8]  The  DODIIS  program 
is  intended  to  facilitate  the  flow  of  information  between  members  of  the  defense  intelligence 
community  by  providing  analyst  access  to  and  maintenance  of  databases  and  services  for 
file  transfers,  information  dissemination,  and  analyst-to-analyst  exchanges  (E-Mail).  [Ref. 
9:p.  1-1] 

DODIIS  has  generally  been  understood  to  encompass  those  automated 
information  systems  (AIS)  and  associated  resources  funded  all,  or  in  part,  by  the  General 
Defense  Intelligence  Program  (GDIP).  DODIIS  has  evolved  from  a  series  of  individual 
systems  development  efforts  into  an  increasingly  interdependent  set  of  subsystems  which 
interact  to  provide  integrated  data  handling  support  for  the  entire  defense  intelligence 
community.  Additionally,  the  DODIIS  program’s  management  structure  ensures  that 
information  systems  developed  and  acquired  for  the  defense  intelligence  community 
conform  with  current  systems  development  principles  and  comply  with  specific  guidance 
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provided  by  the  Congress  and  DoD  in  general.  The  DODIIS  program  has  thus  evolved  into 
a  comprehensive  management  plan  providing  strategic  IS  architectural  guidance  that  is 
specifically  tailored  for  defense  intelligence  organizations  while  complementing  and 
complying  with  the  general  DoD  IS  planning  guidance. 

2.  DODIIS  Program  Guidance 

The  DODIIS  program  was  established  in  1977  by  the  Joint  Chiefs  of  Staff  under 
Defense  Intelligence  Agency  G^IA)  management  in  support  of  the  GDIP.  Since  initiation  of 
Corporate  Information  Management  (CIM)  within  DoD  in  1990,  top-level  oversight  of  the 
DODIIS  program,  systems,  and  resources  has  been  the  responsibility  of  the  Assistant 
Secretary  of  Defense  for  Command,  Control,  Communication  and  Intelligence  (ASD/C3I). 
Other  national  agencies  exercise  influence  over  how  DIA  manages  and  implements  the 
DODOS  program.  DISA  implements  ASD/C3I  policy  with  respect  to  information 
technology  standards,  data  administration,  and  central  acquisition  standards  for  information 
technology  requiring  DIA  compliance.  DISA  also  manages  the  operation  of  the  entire  DoD 
information  systems  inffastmcture,  including  the  existing  Defense  Data  Network  (DDN) 
and  its  Special  Compartmented  Information  (SCI)  portion  known  as  the  Defense  Secure 
Network  3  (DSNET3).  Other  agencies  have  controlling  roles  related  to  the  intelligence 
systems  and  programs  they  manage,  as  in  the  case  of  the  Central  Intelligence  Agency  (CIA) 
and  the  National  Security  Agency  (NSA).  [Ref.  9:p.  1-2] 

DIA  is  primarily  responsible  for  planning,  programming,  and  implementing 
DODnS  within  the  GDIP  resource  process.  This  responsibility  is  directed  by  the  DODIIS 
Management  Board  (DMB)  which  is  chartered  by  the  Director  of  DIA  and  the  Service 


34 


Intelligence  Chiefs.  The  DMB  is  responsible  for  developing  the  management  process  for 
the  DODnS  program.  The  DMB  provides  documented  guidance  to  organizations  seeking 
to  develop  information  systems  and  components  that  support  the  requirements  of  the 
defense  intelligence  community.  This  management  structure  is  intended  to  implement  the 
strategic  IS  planning  for  the  DODIIS  program.  The  stmcture  has  been  developed  to  enable 
the  defense  intelligence  community  to  plan,  design,  develop,  implement,  and  manage  AIS 
components  of  the  DODIIS  program.  [Ref.  9:p.  2-1] 

3.  Architectural  Methodology 

While  the  DODIIS  program  ensures  compliance  with  emerging  DoD-wide 
technical  standards  and  implementing  policy  such  as  that  provided  by  the  TAFIM,  the 
methodology  for  developing  and  migrating  to  an  IS  architecture  specifically  for  an 
intelligence  organization  requires  an  additional  review  of  the  DODIIS  guidance.  In 
particular,  the  DODIIS  Site  Transition  Methodology  (DSTM)  outlines  a  process  for 
planning  and  managing  a  site's  transition  to  an  architecturally  consistent  DoD-wide 
guidance.  A  brief  overview  of  this  methodology  is  provided. 

Like  a  common  site  implementation  methodology,  the  DSTM  is  a  standard 
planning  approach  for  the  acquisition  and  evolution  of  an  IS  architecture.  The 
methodology  begins  with  development  of  an  objective  site  architecture,  documentation  of 
the  current  baseline,  and  development  year-by-year  plan  for  transition  from  the  baseline  to 
the  objective.  Figure  3  provides  an  overview  of  the  transition  methodology.  This  process 
follows  similar  procedures  offered  by  other  planning  methodologies  with  the  order  varying 
slightly.  It  begins  with  development  of  an  objective  site  architecture,  or  target  architecture. 
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The  process  then  calls  for  the  current  site  architecture  or  baseline  to  be  documented  using 
the  same  format  as  the  objective  site  architecture.  Systems  currently  on  site  will  evolve 
towards  the  objective  architecture.  Documentation  guidance  is  provided  by  the  DSTM. 
[Ref.  10;p.  3-1] 
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The  objective  site  architecture  is  identified  based  on  analysis  of  the  site  mission, 


relationships  with  other  sites,  and  the  flow  of  data  into  and  out  of  the  site.  The  analysis 
identifies  the  specific  intelligence  functions  that  should  be  performed  at  the  site  and  justifies 
the  selection  of  specific  standards  and  site  unique  intelligence  applications.  This  process  is 
in  tine  with  strategic  IS  planning  practices  previously  introduced  that  attempt  to  link  the 
business  and  IS  plans  of  the  organization.  The  analysis  process  is  intended  to  identify  the 
intelligence  functions  of  the  organizations  and  map  these  functions  to  appropriate  IS 
applications.  Figure  4  depicts  this  analysis  methodology.  Three  sets  of  data— formal 
mission  documentation,  relationships  between  sites,  and  data  flows  between  sites— are  used 
in  the  analysis. 


Figure  4:  DODIIS  Requirements  Analysis  Methodology  [Ref.  10;p.  4-2] 
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Analysis  of  formal  mission  documentation  typically  reveals  the  general  business 
plan  of  the  organization.  Further  analysis  of  relationships  with  other  sites  (suppliers  and 
customers)  often  will  reveal  additional  capability  requirements  and  provide  insight 
regarding  the  performance  of  formally  defined  missions.  The  DODIIS  site  transition 
methodology  provides  a  one  page  summary  chart  for  recording  these  relationships.  Figure 
5  is  a  example  for  a  “notional”  intelligence  site  with  tasking,  evaluation,  and  support 
relationships  between  the  sites  described.  This  example  uses  a  generic  intelligence  site  with 
possible  relationships  to  a  Joint  Task  Force  (JTF),  the  Defense  Intelligence  Agency  (DIA), 
a  Theater  Joint  Intelligence  Center  (JIC),  as  well  as  Tactical  Users  depicted. 


Figure  5:  Example  Intelligence  Site  Relationships  [Ref.  l():p.  4- 
4] 
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After  reviewing  mission-related  documentation  and  establishing  external 
organizational  relationships,  the  DODIIS  Site  Transition  Methodology  calls  for  further 
analysis  to  be  conducted  that  identifies  information  requirements  by  considering  data  flow 
between  sites.  Data  flows  are  also  summarized  on  a  one-page  chart.  The  data  flows  show 
the  source,  destination ,  and  type  of  inteUigence  data  and  products  (services)  flowing  in  and 
out  of  the  site.  The  format  is  the  same  as  the  organizational  chart,  except  that  the  arrow 
notations  are  used  to  indicate  information  flows  instead  of  relationships.  Figure  6  shows 
an  example  Data  Flow  chart  for  the  same  “notional”  intelhgence  site. 


Figure  6:  Example  Intelligence  Site  Data  Flows  [Ref.  10:p.  4-6] 


The  organizational  and  data  flow  analysis  provides  the  understanding  required  to 
develop  the  baseline  and  objective  site  architectures.  An  understanding  of  the  information 
requirements  is  essential  to  the  development  of  a  strategic  IS  architecture  that  is  aligned 
with  organizational  goals  and  critical  business  functions  of  the  organization.  The  DODIIS 
methodology  is  specifically  designed  for  intelhgence  organizations,  but  is  consistent  with 
previously  reviewed  strategic  IS  planning  methodologies.  In  summary,  the  purpose  of  the 
DODnS  Site  Transition  Methodology  is  to  provide  guidance  for; 

•  Developing  site  implementation  of  the  standard  DODIIS  site  architecture; 

•  Developing  a  site  transition  plan; 

•  Managing  the  transition  using  standard  project  management  techniques. 

E.  INTEGRATING  ARCHITECTURAL  METHODOLOGIES 

The  architectural  IS  planning  methodologies  presented  in  this  chapter  offer  a  broad 
range  of  techniques  which  are  intended  to  assist  in  the  development  of  an  IS  plan  that  is 
strategically  aligned  with  the  critical  business  functions  of  the  organization.  Similar  to  all 
strategic  IS  planning  guidelines,  the  architectural  approaches  offered  by  the  TAFIM  and 
DODIIS  methodologies  emphasize  a  structured  approach  that  can  be  applied  to  both  large 
and  small  organizations.  The  TAFIM  SBA  Planning  Guide  presents  the  step-by-step 
process.  The  DODIIS  guidelines  provide  a  complementary  set  of  steps  with  application 
specifically  useful  for  intelhgence  organizations. 

This  thesis  in  subsequent  chapters  will  use  an  integrated  approach  to  architectural  IS 
planning  that  draws  on  the  techniques  presented  in  this  chapter.  Primarily,  the 
methodology  presented  will  follow  the  structured  steps  of  the  TAFIM  SBA  Planning 
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process.  These  steps  will  form  the  structure  and  outline  for  addressing  the  architectural 
development  issues  at  ONI.  Additionally,  the  techniques  offered  by  the  DODIIS  guidelines 
that  are  specifically  useful  for  intelligence  organizations  will  be  used  when  applicable. 
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III.  INITIATION  AND  ARCHITECTURE  FRAMEWORK 


A.  INTRODUCTION 

This  chapter  will  begin  the  demonstration  of  the  TAFIM  SBA  Planning  process  with 
application  to  the  systems  development  efforts  underway  at  ONI.  As  described  in  the  SBA 
Planning  guide,  phase  one  is  Initiation  and  Architecture  Framework.  Subsequent  phases 
will  be  addressed  in  following  chapters.  As  previously  discussed,  the  entire  planning 
process  described  in  the  SBA  Planning  Guide  will  not  be  attempted.  However,  the 
structure  for  this  chapter  will  be  similar  to  that  envisioned  for  the  Architecture  Framework 
Document  described  in  the  SBA  Planning  Guide.  As  such,  this  chapter  is  intended  to  be 
direction-setting  in  nature.  This  chapter  will  be  structured  around  the  major  deliverables 
described  in  the  SBA  Planning  Guide: 

•  Enterprise  MissionA^ision 

•  Strategic  Drivers 

•  IT  Principles 

•  Key  Issues  Impacting  Architecture  Development 

B.  ONI’s  ENTERPRISE  MISSION  /  VISION 

The  following  quote  is  taken  from  the  ONI  strategic  planning  document  entitled 
Strategic  Planning  for  the  Office  of  Naval  Intelligence:  Vision  and  Direction  for  the  Future 
promulgated  in  July  1992: 

ONI’s  ongoing  intelligence  role  is  now  defined  as  providing  basic  and 

background  maritime  intelligence  for  the  JICs;  providing  support  to  Department 

of  the  Navy  RDT&E,  acquisition,  and  training  functions:  providing  maritime 
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S&T  and  general  military  intelligence  support  to  many  branches  of  the 
Government;  and  support  for  certain  unique  national-level  programs  ...  [In 
this  role]  ONI  is  the  national  resource  and  center  for  excellence  for  maritime 
intelligence  world-wide:  services,  analysis,  special  collection,  training,  and 
technical  resources.  [Ref.  ll:pp.  2-11] 

Subsequent  to  this  initial  planning  document,  the  ONI  leadership  began  a  formal  strategic 
planning  process  in  mid-October  1992.  ONI’s  mission  and  its  vision  statement  were 
reaffirmed  after  carefully  examining  the  environment  within  which  ONI  was  to  operate. 

The  early  planning  initiatives  by  ONI  in  1992  led  to  the  establishment  of  five  “Key 
Issues”  and  associated  accomplishments  to  be  the  focus  for  planning  ONI’s  development 
over  the  succeeding  five  to  seven  years.  These  key  strategic  planning  issues  are  shown  in 
Table  2.  All  of  these  key  issues  will  either  directly  or  indirectly  influence  the  strategic  IS 
planning  process  at  ONI. 

TABLE  2;  ONI’S  KEY  STRATEGIC  PLANNING  ISSUES  [Ref.  12:pp.  3-4] 

Key  Issue  1.  Customers 

Key  Accomplishment:  With  our  customers,  establish  a  clearly  defined  and  accepted 
set  of  relationships,  products,  and  services. 

Key  Issue  2.  Workforce 

Key  Accomplishment:  Create  an  atmosphere  that  promotes  a  motivated  and  capable 
workforce  that  clearly  understands  ONI  goals  and  their  role  in  supporting  them. 

Key  Issue  3.  Resource  Planning 

Key  Accomplishment:  Optimize  resources  to  ensure  the  capability  to  carry  out  our 
responsibilities. 

Key  Issue  4.  Demand-Pull 

Key  Accomplishment:  Support  a  multi-media,  demand-pull  dissemination  system. 

Key  Issue  5.  National  Maritime  Intelligence  Center 

Key  Accomplishment:  Achieve  a  fully  operational  national  maritime  intelligence 
capability  within  the  new  facility. 
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Table  3  summarizes  the  primary  missions  for  ONI.  The  emphasis  in  each  of  the  four 
customer-oriented  missions  is  on  services,  not  products.  In  many  cases,  the  service  will  be 
the  acquisition  of  data  collected  by  ONI  assets  or  by  other  organizations,  the  analysis  and 
fusion  of  that  data,  the  addition  of  explanatory  comments  and  information,  the  tailoring  of 
the  material  for  use  by  the  customer,  and  its  timely  delivery  on-demand  to  the  customer. 
[Ref.  ll:p.  13] 

Finally,  the  ONI  Strategic  Plan  calls  for  a  change  from  the  traditional  production  of: 

...  a  relatively  fixed  slate  of  information  publications  to  providing 
demand-pull  services  to  customers  who  can  tailor  their  own  products  through 
querying  a  universally  responsive,  on-hne  database  from  any  point  on  the 
globe.  That  is  ONI’s  vision,  one  fully  supported  by  the  defense  community, 
but  one  that  will  require  careful  and  comprehensive  planning,  judicious 
expenditure  of  resources,  and  constant  liaison  between  ONI  and  its  customers 
to  bring  to  reality.  [Ref.  12:p.  3] 
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TABLE  3:  ONI  MISSIONS  SUMMARY  [Ref.  ll:p.  12] 


Mission  1  -  Provide  the  Joint  operating  forces,  via  the  Unified  and  Specified 
Commanders’  JICs,  with  intelligence  and  resources  for: 

Naval  ship  and  aircraft  characteristics,  capabilities,  operating  doctrine  and  tactics 

Merchant  ship  information,  locations,  and  tracks 

Environmental  and  geophysical  data 

Tailored  support  for  special  collection  and  operations 

Specialized  tactical  and  operational  analysis 

Identification  of  threats,  vulnerabilities,  and  proactive  opportunities 

Mission  2  -  Provide  the  Department  of  the  Navy  with  intelligence  and  services  for: 

Scientific  and  Technical  Intelligence  to  support  research,  development,  testing,  operational  evaluation 
and  acquisition 

Professional  development  and  training  intelligence  specialists  and  officers 
Requirements  and  planning,  programming,  budgeting  for  intelligence  and  related  systems  tind 
personnel 

Tailored  support  for  special  collection  programs 

Mission  3  -  Provide  National  Security  elements  of  the  Government  with  maritime 
intelligence  and  support  for: 

Counterintelligence  and  security  operations 
Counterterrorism  operations 
Counterdrug  operations 

Nuclear  and  nonnuclear  arms  proliferation  monitoring 
Treaty  and  multilateral  agreement  verification 
Strategic  trade  monitoring  and  global  economic  assessment 
National  intelligence  estimates 

Ocean  resources  and  the  maritime  environment  data  collection 

Mission  4  -  Provide  the  Fleet  and  Fleet  Marines  with  maritime  intelligence  for 
tactical  training,  rehearsal  and  preparation  for: 

Naval  surface  and  undersea  warfare 

--  Cued  by  real  world  tactics,  capabilities,  and  vulnerabilities  of  potentuil  adversaries 
Naval  air  warfare 

--  Cued  by  realworld  air  defense  systems  and  tactics,  capabilities  and  vulnerabilities, 

--  Incorporating  air  defense  and  air  traffic  control  systems  worldwide  as  they  have  been  exported 
Naval  amphibious  and  strike  power  projection  ashore 

-  Cued  by  realworld  coastal  and  interior  environments  and  defenses 

-  Incorporating  air  and  land  defense  systems  worldwide  as  they  have  been  exported  or  developed 
Special  Mission:  In  addition  ONI  also  must  support  certain  national  level  programs. 
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C.  STRATEGIC  DRIVERS 


1.  Key  Strategic  IS  Planning  Initiatives 

Recent  C4I  systems  development  within  DoD  has  been  guided  by  several  key 
initiatives  developed  during  the  late  1980s  and  early  1990s.  These  initiatives  have  provided 
a  vision  for  information  management  within  DoD  and  directly  influence  current  and  future 
systems  development  efforts  within  the  Navy  and  at  ONI.  These  initiatives  emphasize  the 
common  theme  of  providing  timely  and  accurate  information  to  the  user,  creating  an 
interoperable  information  environment  across  DoD. 

In  order  to  understand  and  effectively  evaluate  critical  C4I  systems  development 
decisions,  these  key  policy  initiatives  must  be  examined.  The  guidance  provided  by  these 
initiatives  is  reflected  in  recent  C4I  systems  integration  efforts  within  the  Navy.  This 
section  will  examine  these  initiatives  and  attempt  to  provide  an  understanding  of  the 
resulting  current  and  future  systems  development  trends. 

a.  DoD’s  Corporate  Information  Management  (CIM) 

Defense  Management  Review  Decision  (DMRD)  9 1 8  provided  support  for 
the  Corporate  Information  Management  (CIM)  initiative  administered  by  the  Defense 
Information  Systems  Agency  (DISA).  CIM  is  a  strategic  management  initiative  intended  to 
guide  the  evolution  of  the  DoD  enterprise  by  capturing  the  benefits  of  the  information 
revolution.  It  emphasizes  both  a  functional  and  technical  management  focus  to  achieve  a 
combination  of  improved  business  processes  and  effective  application  of  information 
technology  across  the  functional  areas  of  DoD.  It  is  embodied  in  policies  and  programs, 
implementation  guidance,  and  supporting  resources,  to  help  functional  managers  guide  and 
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implement  changes  to  processes,  data,  and  systems  across  the  DoD.  [Ref.  13:p.  1] 

The  management  structure  of  CIM  has  four  “pillars”  that  support  improved 
Defense  capabilities:  common  information  systems;  shared,  standard  data;  re-engineered 
processes;  and  a  computer  and  communications  infrastructure.  The  overarching  goal  of 
CIM  is  to  enable  commanders  of  mihtary  forces  and  managers  of  support  activities  to 
achieve  the  highest  degree  of  capability  in  their  operations  through  the  effective  use  of 
information  applied  in  improved  functional  processes.  The  vision  of  this  initiative  provides 
for  global  end-to-end  information  connectivity  among  U.S.  and  alhed  forces.  In  this 
context,  information  is  considered  a  critical  mission  capability  and  force  multiplier  for 
worldwide  readiness,  mobility,  responsiveness,  and  operations.  Joint  interoperability  and 
information  integration  on  the  battlefield  is  emphasized  to  result  in  significantly  improved 
joint  service  and  multinational  operations.  [Ref.  13:p.  3] 

b.  The  Joint  Staffs  ‘*C4I  for  the  Warrior^^ 

C4I  for  the  Warrior  is  a  concept  for  DoD  information  management  first 

published  by  the  Joint  Chief’s  of  Staff  in  1992.  It  is  clearly  targeted  at  solving  the  C41 

interoperability  issues  among  the  services.  The  intent  is  to  provide  an  unifying  C4I  concept 

that  will  support  the  requirements  of  the  joint  force  Warrior  at  the  battlefield  level,  while 

remaining  consistent  with  DoD  policy  and  national  security  objectives.  This  focus  is 

expressed  by  former  Chairman,  General  Colin  L.  Powell,  in  the  following  statement: 

The  C4I  for  the  Warrior  concept  will  give  the  battlefield  commander  access 
to  all  information  needed  to  win  in  war  and  will  provide  the  information  when, 
where,  and  how  the  commander  wants  it  The  C4I  for  the  Warrior  concept 
starts  with  the  Warrior’s  requirements  and  provides  a  road  map  to  reach  the 
objective  of  a  seamless,  secure,  interoperable  global  C4I  network  for  the 
Warrior.  [Ref.  14] 
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C4I  for  the  Warrior  is  considered  a  seminal  doctrine  that  is  intended  to  guide  the  evolution 
of  individual  service  C4I  architectures  into  a  broad  Global  Command  and  Control  System 
(GCCS)  [Ref.  15:p.  49].  The  concept  principles  have  been  incorporated  in  the  Joint 
Staff’s  GCCS  program. 

At  the  center  of  the  C4I  for  the  Warrior  concept  is  the  establishment  of  a 
global  C4I  capability  that  allows  the  Warrior  to  define  the  battle  space  and  to  “plug  in”  and 
“pull”  timely,  relevant  information  anytime,  anyplace  in  the  performance  of  any  mission. 
The  Warrior,  by  defining  the  battle  space,  determines  the  information  to  “pull”  rather  than 
have  information  “pushed”  from  various  sources.  The  Warriors  neither  want  nor  need  the 
cumulative  knowledge  of  multiple  sources  dumped  into  their  battle  space  information 
systems.  They  want  only  the  specific  information  they  need  to  win  the  fight;  and  they 
want  it  when  they  need  it,  where  they  need  it,  and  in  the  form  in  which  it  will  do  them  the 
most  good.  This  demand  pull  concept  provides  the  capability  for  the  Warrior  to  poll  the 
global  C4I  network  for  any  desired  information  from  any  location,  at  any  time.  This  is  a 
key  principle  of  the  C4I  for  the  Warrior  concept  and  a  guiding  concept  for  future  DoD  and 
Navy  C4I  architecture  development. 

c.  The  Navy’s  Copernicus  Architecture 

The  Copernicus  Architecture  is  the  current  architectural  guidance  designed  to 
restructure  all  Navy  C41  systems.  The  Copernicus  Architecture,  Phase  I :  Requirements 
Definition,  published  in  1991,  provides  both  a  new  C41  architecture  to  replace  the  current 
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Navy  system  and  a  programmatic  investment  strategy  to  constmct  it  over  the  next  decade. 
It  is  intended  to  establish  a  vision  of  an  overall  C4I  architecture  for  the  Navy.  [Ref.  16:p. 
3-2] 

The  Copernicus  Architecture  is  primarily  a  telecommunications  system 
designed  around  a  series  of  global  information  exchange  systems  ashore  and  tactical 
information  exchange  systems  afloat.  The  architectural  concept  is  based  on  four  pillars: 
first,  virtual  global  networks  called  Global  Information  Exchange  Systems  (GLOBIXS); 
second,  metropolitan  area  networks  called  CINC  Command  Centers  (CCC);  third,  tactical 
virtual  nets  called  Tactical  Data  Information  Exchange  Systems  (TADIXS);  and  fourth, 
interconnecting  the  previous  systems  to  support  the  Tactical  Command  Center  (TCC) 
afloat.  In  this  concept,  data  can  be  forwarded  from  the  shore  based  sensor-to-sensor 
infrastmcture  to  the  tactical  commander’s  C2  infirastructure  afloat.  This  new  system  has 
been  designated  Copernicus  as  it  is  centered  on  the  tactical  needs  of  the  operator  afloat. 
[Ref.  17:pp.  10-12] 

A  key  concept  of  the  Copernicus  Architecture  is  the  recognition  of  the  Space 
and  Electronic  Warfare  Commander  (SEWC)  as  part  of  the  Composite  Warfare 
Commander  (CWC)  doctrine  afloat.  This  action  follows  the  establishment  of  SEW  as  a 
designated  warfare  area  within  the  Navy  by  the  CNO  in  1989,  which  doctrinally  assigned 
command  and  control  (C2)  functions  to  the  SEW  mission.  In  many  ways,  this  early 
recognition  of  the  importance  of  information  management  for  the  operational  commander 
served  as  a  building  block  for  further  DoD  architecture  development.  The  Copernicus  goal 
of  establishing  a  “common  operating  environment”  now  is  considered  part  of  the  Defense 
Department’s  “C4I  for  the  Warrior”  initiative,  which  requires  the  Army,  Navy,  and  Air 
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Force  to  develop,  through  a  phased  process,  approaches  to  making  their  C4I  data-transfer 
systems  fully  compatible  for  joint  operations.  [Ref.  15:p.  49] 

d.  Summary  of  Key  Policy  Initiatives 

The  policy  initiatives  reviewed  in  this  section  have  provided  the  fundamental 
guidance  for  recent  systems  development  throughout  DoD  and  within  the  Navy.  These 
initiatives  present  the  common  theme  of  support  to  the  operational  commander  or  Warrior 
through  an  integrated  strategic  information  management  infrastructure  and  the  development 
of  interoperable  C4I  systems.  These  initiatives  present  a  consistent  view  of  C41  from  the 
afloat  operational  commander  to  the  Unified  CINCs  crossing  all  DoD  functional  areas.  The 
impact  of  these  policy  and  strategy  initiatives  is  reflected  in  recent  C4I  systems 
development  efforts  and  has  influenced  the  actual  deployment  and  delivery  of  operational 
C4I  systems  to  the  field. 

2.  Key  IS  Development  Directives 

a.  OSD  Guidance  for  C4I  Systems  Development 

Additional  policy  guidance  has  been  incorporated  into  more  recent  national 
military  planning  strategy  and  DoD  directives  to  reflect  the  goals  of  these  key  initiatives 
reviewed  in  the  previous  section.  As  a  result,  new  systems  are  being  development  in  line 
with  joint  doctrine.  DoD  Directive  4630.5  states,  “That  for  the  purposes  of  compatibility, 
interoperability,  and  integration,  all  C3I  systems  developed  for  use  by  US  forces  are 
considered  to  be  for  joint  use.”  The  National  Military  Strategy  Document  (NMSD)  for  FY 
1994-1999  establishes  C4I  as  the  overarching  C4  programming  objective.  The  NMSD’s 
reiterates  the  concepts.  “Consistent  with  the  ‘C4I  for  the  Warrior’  plan,  all  Service-  and 
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Agency-programmed  systems  must  be  compatible  and  interoperable  to  support  joint  and 
combined  operation  across  the  entire  spectrum  of  conflict.”  [Ref.  18:p.  18] 

DoD  systems  development  efforts  have  recently  been  given  further  direction 
in  order  to  programmatically  achieve  the  goals  of  the  strategic  initiatives.  The  elimination 
of  duplication  and  technical  obsolescence  among  C4I  systems  currently  in  service  across 
DoD  prompted  direction  from  Deputy  Secretary  of  Defense  Perry  in  a  memorandum  of 
October  13, 1993.  This  memo  directed  an  accelerated  process  for  selection  of  systems  to 
be  included  in  set  of  “migration”  systems.  It  also  directed  all  development  and  expenditure 
for  “legacy”  systems  to  be  terminated  within  three  years.  In  compliance  with  DoD 
initiatives,  complete  data  standardization  is  also  to  be  achieved  throughout  C41  systems 
within  three  years. 

Further  direction  from  Assistant  Secretary  of  Defense  Paige  in  a 
memorandum  of  December  20, 1993,  provided  minimum  specific  evaluation  criteria  for 
selecting  C4I  systems  for  migration.  It  is  important  to  note,  as  stated  in  this  memo,  that 
“. . .  the  perspective  of  the  war  fighter  must  be  maintained  throughout  the  selection 
process.”  [Ref.  19]  Additionally,  guidance  provided  with  this  memo  indicated  that  the  loss 
of  system  functionality  would  not  be  considered  as  Justification  to  delay  the  migration 
system  selection  process. 

AU  of  these  directives  are  intended  to  guide  C41  systems  development  in  this 
era  of  declining  human  and  financial  resources,  increasing  requirements,  and  resultant 
compressing  schedules.  As  these  directives  indicate,  program  managers  must  design, 
develop,  procure,  and  support  affordable  systems  necessary  to  meet  Naval  and  joint  C41 
requirements  in  the  face  of  these  constraints. 
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b.  DNI  Guidance  for  ONI  Systems  Development 

The  key  strategic  initiatives  and  planning  guidance  provided  will  have  a 
direct  impact  on  ONI  systems  architecture  development  efforts.  Many  systems  now  used  at 
ONI  have  been  identified  as  legacy  systems.  Those  systems  may  be  dropped  completely. 
The  unique  functionality  of  those  legacy  systems  must  be  merged  with  a  migration  system 
if  functionality  is  to  be  maintained  and  further  supported. 

In  line  with  the  current  systems  development  environment  within  DoD, 
policy  direction  from  the  Director  of  Naval  Intelligence  (DNI)  has  stressed  compatibility 
and  interoperability  of  ONI  systems  with  DoD-wide  efforts.  ONTs  systems  development 
efforts  over  the  last  decade  have  been  supported  by  the  Naval  Command,  Control,  &  Ocean 
Surveillance  Center  (NCCOSC),  Research,  Development,  Tests,  &  Evaluation  Division 
(NRaD),  the  Navy’s  lead  C4I  systems  development  agency.  Given  that  the  genesis  of  the 
new  Global  Command  and  Control  System  (GCCS)  is  the  Joint  Maritime  Command 
Information  System  (JMCIS),  the  basis  exists  to  implement  within  ONI  a  truly 
interoperable,  open  systems,  C4I  architecture  that  will  support  national,  theater,  and  tactical 
customers.  Recent  development  efforts  at  NRaD  have  been  focused  on  design  and 
implementation  of  a  common  architecture  and  structure  that  can  accommodate  unique  ONI 
analytical  requirements  within  the  JMCIS  framework.  In  a  memorandum  of  September  10, 
1993,  the  DNI  directs  that  “. . .  as  a  matter  of  policy,  all  ONI  systems  development  will  be 
accomplished  in  strict  adherence  with  the  JMCIS  architecture  and  its  established  systems 
development  procedures.”  [Ref.  2] 
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D.  DEVELOPING  ONI’s  IT  PRINCIPLES 


After  reviewing  ONI’s  strategic  planning  guidance,  several  key  IT-related  issues 
become  apparent.  Additional  issues  of  concern  have  been  obtained  during  personal 
interviews  with  key  management  and  technical  personnel  at  ONI  and  NRaD.  It  is  the 
general  goal  of  ONI  to  build  an  IS  architecture  that  supports  its  customers  and  its  own 
mission-critical  functions  with  responsive  data  bases  and  on-line  infonnation  services. 

This  architecture  development  is  to  be  accomplished  consistent  with  DoD-wide  IS 
architectural  initiatives.  These  IT-related  issues  must  be  specifically  addressed  in  the 
strategic  IS  planning  process.  They  are  essential  to  creating  an  IS  plan  that  will  support  the 
strategic  vision  of  ONI  and  will  be  reflected  in  its  IT  principles.  The  section  provides  a  few 
suggested  IT-principles  to  be  used  in  ONI’s  architecture  development  effort.  This  is 
obviously  not  an  exhaustive  list,  but  is  provided  to  demonstrate  the  concept  of  developing 
IT-principles  to  guide  the  architectural  IS  planning  process. 
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.  Meta-Principles 


Principle 

Implement  a  demand-pull  capability  for  ONTs  intelligence 
dissemination. 

Rationale 

The  ONI  strategic  vision  calls  for  serving  . .  its  customers  in  the  most  efficient  and 
effective  way  possible.”  The  emphasis  is  placed  on  identifying  opportunities  and 
developing  new  methodologies  to  accelerate  change  in  the  way  intelligence  is  delivered. 
Traditional  supplier-push  systems,  in  which  the  intelligence  producer  creates  and  sends  to 
the  customer  hard  copy  covering  “everything  the  customer  might  need  to  know,”  must 
evolve,  where  warranted,  to  demand-puU  systems,  in  which  intelligence  is  provided  “on 
demand”  to  the  customer,  tailored  to  a  particular  user’s  immediate  requirements. 

Implications 

This  concept  will  require  ONI  to  transition  from  a  document  and  database  orientation 
to  an  information-based  orientation,  transforming  itself  from  a  document  producer  to  an 
information  service  provider.  This  requires  structuring  intelligence  in  such  a  way  that  the 
customer  is  able  to  access  any  data,  database,  or  information  related  to  a  general  concept. 
Achieving  a  concept  oriented  demand-pull  dissemination  architecture  will  require  an 
integrated  concept  of  operations,  adherence  to  standards,  and  systems  interoperability  at 
multiple  levels.  [Ref.  12:p.  25] 


Principle 

All  ONI  systems  development  will  remain  consistent  with 
DoD-wide  strategic  IS  initiatives. 

Rationale 

ONI’s  Strategic  Plan  specifically  recognizes  two  IS  architectural  initiatives 
. .  which  [will]  affect  the  way  ONI  will  communicate  with  its  operational  customers.” 
The  vision,  goals,  and  actions  planned  by  ONI  specific  address  for  these  two  initiatives; 

1.  The  Copernicus  architecture,  which  caUs  for  fundamental  changes  in  the  C3I 
architecture  of  the  Navy,  especially  with  respect  to  the  development  of  a  global  C3I 
network. 

2.  The  Corporate  Information  Management  or  CIM  initiative,  whereby  all  DoD 
databases  will  become  interoperational  through  standardized  formats,  syntax,  and 
semantics.  [Ref.  ll:p.  10] 

Implications 

As  ONI  systems  exist  now,  and  as  they  continue  to  move  on-line,  they  must  conform 
to  the  CIM  Standards  wherever  possible.  Where  this  is  not  possible,  action  must  be  taken 
to  extend  or  modify  CIM  Standards  to  accommodate  the  particular  needs  of  maritime 
intelligence  and  decisions  made  with  regard  to  evolutionary  compatibility  with  CIM.  [Ref. 
ll:p.  22] 

A  driving  concept  of  Copernicus  is  the  emphasis  on  demand-pull  data  services  as 
opposed  to  supply-push  data  production.  This  concept  is  in  full  accordance  with  ONTs 
goal  to  emphasize  services  vice  products. 


Principle 

All  ONI  systems  development  will  be  accomplished  in  strict 
adherence  with  the  JMCIS  architecture  and  its  established 
systems  development  procedures. 

Rationale 

This  approach  will  enable  ONI  to  provide  maritime  intelligence  to  a  broad  consumer 
base  while  affording  the  greatest  degree  of  compatibility  with  Navy  C4I  systems 
converging  under  the  JMCIS  and  GCCS  architectures.  JMCIS  has  been  identified  as  the 
primary  migration  system  for  Navy  C2.  It  will  also  allow  for  further  support  of  unique 
ONI  systems  functionality  that  would  otherwise  be  terminated  as  legacy  systems  are 
discontinued.  It  will  allow  ONI  to  maintain  future  IS  expenditures  within  requisite  fiscal 
boundaries.  JMCIS  provides  an  open  systems  architecture. 

Implications 

The  functional  requirements  of  legacy  systems  at  ONI  must  be  clearly  identified  for 
migration  to  the  JMCIS  architecture.  Existing  intelligence  analysis  applications  will  require 
integration  into  the  JMCIS  architecture  and  existing  maritime  data  bases  will  require 
consolidation  into  a  centralized  system.  This  effort  will  constitute  the  development  of  ONI 
Intelligence  Segment(s)  within  the  JMCIS  architecture. 
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Principle 

All  ONI  systems  development  will  be  in  consonance  with 
DODIIS  and  TAFIM  guidelines. 

Rationale 

In  a  January  1993  memorandum,  then  Director  of  Defense  Information  Mr.  Paul 
Strassman  stated  that  “The  Technical  Architecture  Framework  for  Information  Management 
(TAFIM)  will  serve  as  the  single  framework  [to  achieve  integration] . . .  and  drive  systems 
design,  acquisition,  and  reuse  throughout  DoD.”  It  was  further  directed  that  all  new  DoD 
information  systems  development  and  major  modernization  programs  will  use  the  TAFIM. 
TAFIM  guidelines  provide  a  stmctured  approach  to  architectural  IS  planning  that  will 
ensure  ONI  systems  achieve  compatibility  and  interoperability  with  the  broadest  possible 
consumer  base.  The  additional  guidance  provided  through  DODIIS  will  ensure  ONI 
systems  are  aligned  with  those  in  the  defense  intelligence  community. 

Implications 

The  migration  systems  will  form  the  foundation  for  future  C4I  architectures  and  are  in 
consonance  with  DODIIS  and  the  TAFIM  standards.  ONI  efforts  to  confonn  with 
migration  systems  architectures,  such  as  JMCIS,  will  ensure  compliance. 
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2.  Information  Management 


Principle 

Create  the  National  Maritime  Intelligence  Database  (NMID). 
Rationale 

As  the  principal  basis  for  the  future  functioning  of  ONI,  the  National  Maritime 
Intelligence  Database  (NMID)  is  envisioned  to  be  a  multimedia,  multilevel-secure,  on-line, 
and  on-demand  service  formed  by  the  integration  and  extension  of  products,  services,  and 
data  bases  currently  maintained  at  ONI.  The  NMED  is  intended  to  serve  as  the  principal 
national  information  source  for  maritime  intelligence  and  associated  data  including  naval, 
merchant-marine,  environmental,  and  scientific  and  technical  information.  [Ref.  1  l:p.  20] 

Implications 

Within  the  context  of  shifting  the  emphasis  from  products  to  services,  the  NMID  will 
furnish  three  classes  of  services: 

•  On-line  query-response  services, 

•  Subscription  services,  using  communications,  electronic,  optical,  and  paper 
media,  and 

•  Outputs  at  ONI’s  own  initiative  when  required,  responding  to  interest  profiles 
maintained  by  its  customers. 

NMID  outputs,  on  consumer  request,  will  be  via  query-response  interaction  directly  with 
the  NMED.  The  dissemination  of  standardized  ONI  data  products  will  evolve  into  an  on- 
demand  system  that  incorporates  broadcast  and  other  broad  dissemination  via  subscription 
services,  extending  the  primary  service  of  query-response  alerting  to  any  and  all  qualified 
consumers.  Within  this  concept,  the  customer  will  clearly  establish  data  requirements  as 
weU  as  directly  influence  analysis  priorities  and  create  interest  profiles.  [Ref  1 1  :pp.  20-21] 
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3.  Application  Management 


Principle 

Assure  that  local  and  external  user  requirements  are 
satisfied  with  all  systems  development  and  acquisition  processes, 
retaining  the  unique  analytical  functionality  that  current 
applications  provide  to  ONI  intelligence  analysts. 

Rationale 

A  primary  concern  is  that  the  unique  analytical  capabihties  of  ONI  that  are  currently 
supported  with  various  information  systems  and  appUcations,  such  as  those  specific  to 
Civil  Maritime  Analysis,  will  continue  to  be  supported  in  any  new  architecture.  Migrating 
to  a  new  architecture  with  new  systems  can  mean  trading  systems  maturity  and  reliable 
services  of  legacy  systems  for  flexibility,  openness,  and  unreliable  services  of  new 
systems. 

Implications 

Again,  the  functional  requirements  of  legacy  systems  at  ONI  must  be  clearly 
identified  for  migration  to  the  new  architecture.  Existing  intelhgence  analysis  applications 
wiU  require  integration  into  the  new  architecture  and  existing  maritime  databases  will 
require  consolidation  into  a  centralized  system.  Testing  and  validation  will  be  critical  to 
ensure  functionality  is  maintained  to  an  acceptable  level. 
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4.  Technology  Management 


Principle 

ONI  systems  will  migrate  to  an  open  systems,  clientlserver 
environment. 

Rationale 

Client/Server  is  a  flexible  architecture  that  allows  for  integration  of  current  systems  in 
a  distributed  environment.  Client/Server  is  argued  to  be  the  most  logical  means  of 
realigning  the  IS  architecture  because  it  exploits  the  same  perceived  advantages  of  desktop 
computing,  such  as  the  reduced  hardware  and  software  costs,  with  increasingly  powerful 
performance  capabilities,  while  creating  an  environment  that  is  responsive  to  the  business 
needs  of  an  organization.  Other  unique  advantages  include: 

•  System  flexibility:  The  increasing  standardization  of  protocols  and  “open 
systems”  permits  ad-hoc  integration  of  disparate  platforms.  This  environment  is 
conducive  to  changing  requirements  for  and  allows  the  integration  of  old 
technology  with  new  technology. 

•  Vendor  independence:  As  more  protocols  and  systems  become  standardized  and 
open,  users  can  select  the  system  that  provides  the  desired  functionality. 

•  Reliability:  In  a  client/server  environment  there  is  enough  redundancy  and 
machine  independence  to  allow  operations  to  continue.  [Ref.  20:pp.  33-34] 

Implications 

This  migration  process  is  clearly  underway  at  ONI.  The  inevitable  implications  of 
technological  flexibility  offered  by  the  client/server  environment  has  been  increased 
architecture  design  and  configuration  management  complexity.  In  the  client/server 
environment,  a  network  composed  of  mainframes  and  powerful  desktop  computers  can  all 
play  a  role.  Configuration  management  and  network  management  must  be  thoughtfully 
considered. 
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E.  KEY  ISSUES  IMPACTING  ARCHITECTURE 
DEVELOPMENT 

This  section  reviews  some  of  key  findings  previously  presented  to  ONI  in  the  thesis. 

Downsizing  Information  Systems:  Framing  the  Issues  for  the  Office  of  Naval  Intelligence, 
completed  by  Lieutenant  Peter  Hutson  in  March  1994.  These  concerns  have  been 
commonly  found  in  the  commercial  sector  and  are  derived  from  corporate  lessons  learned. 
This  direction-setting  phase  highlights  issues  relating  to  current  IS  architecture  development 
efforts  at  ONI.  These  issues  should  be  kept  in  mind  as  the  architecmral  planning  process 
progresses. 

1.  Organizational  Considerations 

•  An  understanding  of  business  needs  is  critical.  IT  can  only  be  a  strategic  asset  to  the 
extent  that  it  supports  the  corporate  strategy.  Analysis  of  critical  success  factors  in 
strategic  IS  planning  may  serve  as  an  essential  first  step. 

•  Top  management  support  is  an  essential  prerequisite.  It  is  an  absolute  necessity  to  the 
success  of  the  effort  that  top  corporate  officials  have  “bought  off’  on  the  idea. 
Architectural  IS  planning  must  be  part  of  the  general  strategic  planning  process. 

•  Resistance  to  change  should  be  anticipated  and  managed.  IS  architectural  change  will 
provoke  resistance.  Proactive  steps  that  facilitate  communications  and  understanding 
throughout  the  organization  must  be  taken  to  counter  potentially  negative  reactions. 

2.  Architectural  and  Technical  Considerations 

•  Migration  strategy  is  a  critical  decision.  Organizations  need  to  decide  to  either  (1) 
grow  with  their  traditional  mainframes,  (2)  fade  out  the  mainframe  while  preparing 
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replacement  systems,  or  (3)  kill  the  mainframe  as  quickly  as  possible.  Commitment 
to  a  global  strategy  should  help  guide  other  decisions.  Determining  the  optimal  time 
to  change,  as  well  as  the  rate  of  change,  should  also  be  considered  when  selecting  a 
migration  strategy. 

Downsizing  and  migration  decisions  can  mean  ti'ading  systems  maturity  and 
integrated  services  of  legacy  systems  for  flexibility,  openness,  and  unintegrated 
services  of  distributed  systems.  Despite  their  proprietary  nature  and  expense,  many 
corporations  are  unwilling  to  move  mission-critical  systems  to  an  unproven, 
immature  desktop  environment. 

Throughput  capabilities  remain  a  major  strength  of  the  mainframe.  The  mainframe 
has  been  optimized  to  support  high  volume  and  complex  data  management  with  large 
bandwidth  and  the  ability  to  manage  multiple  complex  tasks.  The  most  advanced  and 
developed  desktop  systems  are  just  beginning  to  compete  with  the  mainframe  in  this 
area. 

3.  Cost  Considerations 

CostlBenefit  analysis  must  include  conversion  costs  and  costs  of  operating  in  the  new 
environment.  Often  the  costs  associated  with  conversion  are  overshadowed  by  the 
promises  of  cost  savings  in  a  new  environment.  Up-front  conversion  costs  to 
distributed  systems  can  represent  a  sizable  investment. 
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IV.  BASELINE  CHARACTERIZATION 


A.  INTRODUCTION 

This  chapter  continues  the  structured  approach  to  architecture  development  as 
presented  in  the  TAFIM  SBA  Planning  Guide  with  phase  two,  the  baseline 
characterization.  The  purpose  of  this  phase  is  to  determine  the  organization’s  current  IS 
environment  and  create  a  report  that  characterizes  the  existing  architecture  of  the  enterprise. 
“A  clear  view  of  the  existing  IT  architecture  allows  identification  of  opportunities  for 
change.  .  .”  [Ref.  7;Vol.  4,p.  3-1] 

The  term  “characterization”  is  used  because  the  data  gathering  and  analysis  are  not 
exhaustive.  It  is  not  necessary,  nor  is  it  desirable,  to  expend  the  time  and  effort  to 
document  every  detail  of  the  current  architecture.  Only  enough  detail  is  gathered  to  allow 
informed  decisions  to  be  made  with  regard  to  the  desired  target  architecture.  The  SBA 
Planning  Guide  emphasizes  a  “fast  path”  approach  to  the  baseline.  It  recommends  “. . .  a 
generic  baseline  versus  a  detailed  specific  baseline.”  [Ref.  7:Vol.  4,p.  3-1]  It  suggests  as  a 
rule  of  thumb,  that  “. . .  80  percent  of  the  information  used  in  an  architecture  design 
activity  derives  from  20  percent  of  the  data  collected.”  [Ref.  7:Vol.  4,p.  3-2]  Figure  7 
illustrates  the  data  collection  dilemma  indicating  the  inefficiency  of  spending  time  collecting 
the  last  20  percent  of  the  data  when  80  percent  is  sufficiently  accurate  to  characterize  the 
current  environment. 

As  described  in  the  SBA  Planning  Guide,  the  baseline  characterization  is  intended  to 
produce  a  high-level  description  of  the  existing  architecture  along  four  key  dimensions,  or 
views;  work,  information,  applications,  and  technology.  This  chapter  and  the  baseline 
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characterization  presented  will  be  structured  around  these  four  views: 

•  Work  Organization  View 

•  Information  View 

•  Application  View 

•  Technology  View 

B.  WORK  ORGANIZATION  VIEW 

As  described  in  the  SBA  Planning  Guide,  the  baseline  inventory  includes  a 
characterization  of  all  the  business  functions  and  the  key  processes  that  support  the 
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missions  of  the  organization.  The  work  organization  view  follows  from  the  initiation  and 
architectural  framework  phase  by  linking  the  specific  missions  of  the  organization  to  the 
supporting  business  functions.  Similarly,  the  characterization  of  key  processes  follows  the 
requirements  analysis  methodology  outlined  in  the  DODIIS  Site  Architecture  guidance. 

1.  Organizational  Structure 

The  physical  work  structure  of  an  organization  often  does  not  accurately 
represent  the  actual  business  functions  performed.  Examining  a  hierarchical  structure  chart 
or  line  diagram  provides  an  view  of  how  the  people  and  work  groups  are  organized  for 
management  purposes.  Examining  the  work  group  structure  of  an  organization  can  provide 
a  first  glance  understanding  of  the  organization,  but  it  does  not  reveal  the  business 
functions  and  key  processes  performed  by  the  organization  as  a  whole,  which  often  cut 
across  organizational  boundaries.  A  broader  functional  analysis  is  required  to  characterize 
the  work  organization  view  in  terms  of  information  requirements  for  identification  of  the  IS 
services  required  to  support  critical  business  functions. 

The  Intelligence  Directorate  (ONI-2)  performs  a  broad  range  of  substantive 
intelligence  analysis  functions.  These  functions  include  scientific  and  technical  analysis  as 
well  as  general  military  intelligence  analysis.  Intelligence  production  supports  naval 
missions  and  functions  to  include: 

•  strategic  commerce,  seaborne  weapons  transfers,  and  embargoes; 

•  integrated  regional  naval  threat  analysis  and  support  to  the  National  Intelligence 
Estimate  (NIE)  process; 

•  surface  and  coastal  warfare  threat  analysis  and  dissemination; 
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•  air,  electronic,  and  strike  warfare  threat  analysis  and  dissemination; 

•  undersea  warfare  analysis  and  evaluation  of  vulnerabilities. 

Figure  8  depicts  the  organizational  chart  of  ONI-2  reflecting  these  mission  areas. 


Figure  8:  Intelligence  Directorate  (ONI-2)  Organizational 

Chart 


2.  Business  Functions 

The  Civil  Maritime  Analysis  Department  (ONl-21)  focuses  its  analytical  efforts 
primarily  on  the  non-military  use  of  the  sea.  This  focus  includes  maintaining  current  and 
historical  information  concerning  the  characteristics,  capabilities,  disposition,  operations, 
control,  trade  patterns,  and  cargo  of  all-flag  merchant,  fishing,  and  research  vessels.  This 
information  supports  analysis  related  specifically  to  seaborne  arms  transfers,  embargo  or 
sanctions  monitoring,  counter-drug  support,  strategic  trade  monitoring,  international 
smuggling,  control  of  illegal  immigration,  seaborne  terrorism,  and  piracy. 
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The  Integration  and  Regional  Analysis  Department  (ONl-22)  focuses  its 
analytical  efforts  primarily  on  specific  threat  country  or  theater  strategic  issues.  The 
analysis  typically  addresses  issues  that  impact  overall  force  structures  and  multiple  warfare 
areas.  In  this  capacity,  ONI-22  provides  coordination  or  support  for  issues  of  common 
interest  to  the  Intelligence  Directorate  (ONl-2)  as  a  whole.  Analytical  functions  of  this 
department  specifically  include  assessments  of  foreign  naval-related  technologies, 
monitoring  of  global  weapons  development  infrastructures,  supporting  arms-control 
negotiations,  monitoring  regional  military-political  and  economic  developments,  and 
analysis  of  operational  employment  of  foreign  strategic  forces  where  the  interests  of  U.S. 
Naval  forces  are  involved.  ONl-22  also  provides  a  24-hour  watch  that  includes  watch 
personnel  in  the  National  Military  Joint  Intelligence  Center  (NMJIC)  and  Naval  Command 
Center  providing  timely  assessments  of  significant  foreign-maritime  developments  to  the 
Joint  Chiefs  of  Staff,  the  Secretary  of  the  Navy,  the  Chief  of  Naval  Operations,  the 
Director  of  Naval  Intelligence,  and  other  key  decision  makers. 

The  Surface  and  Coastal  Warfare  Department  (ONI-23)  focuses  analysis 
specifically  on  hostile  foreign  naval  operations  that  pose  a  potential  near-term  threat  to  U.S. 
Naval  surface  operations.  The  analysis  is  related  to  mine  warfare,  coastal  defenses,  anti¬ 
landing  capabilities,  and  anti-ship  capabilities  of  foreign  navies.  ONl-23’s  intelligence 
reporting  and  dissemination  directly  supports  U.S.  Naval  forces  as  well  as  the  national  and 
defense  intelligence  process.  Additionally,  support  is  provided  to  training  and  weapons 
acquisition  programs  relying  on  foreign  naval  capabilities  and  performance  information. 

The  Strike  and  Air  Warfare  Department  (ONI-24)  focuses  analysis  specifically 
on  foreign  air  and  space  operations  including  tactics,  training,  and  readiness.  Threat 
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analysis  is  conducted  to  determine  capabilities,  performance,  and  potential  vulnerabilities  of 
foreign  strike  and  air  warfare  platforms.  Likewise,  the  Undersea  Warfare  Department 
(ONI-25)  focuses  its  analytical  efforts  specifically  on  foreign  naval  submarine  and  anti¬ 
submarine  warfare  operations  including  tactics,  training,  and  readiness.  Threat  analysis  is 
conducted  to  determine  capabilities,  performance,  and  potential  vulnerabilities  of  foreign 
undersea  warfare  platforms  and  systems.  Reporting  and  dissemination  directly  support 
U.S.  Naval  forces  and  various  national  and  military  agencies. 

Examining  the  organizational  structure  of  ONl-2  provides  a  general 
understanding  of  the  mission  areas  while  a  more  thorough  examination  reveals  the  business 
functions  that  support  the  missions  areas.  A  functional  analysis,  independent  of  mission 
area,  provides  a  better  understanding  of  the  roles  and  processes  that  are  common  across  the 
physical  organization.  It  is  these  roles  and  key  processes  that  identify  and  best  characterize 
the  critical  business  functions  of  the  organization.  Table  4  below  provides  a  summary  of 
the  maritime  intelligence  roles  supported  by  the  analytical  functions  performed  within 
ONI-2. 

3.  Key  Processes 

An  analysis  of  the  primary  missions  areas  and  supporting  business  functions 
performed  within  ONI-2  reveals  a  few  key  processes  that  are  common  among  each  work 
group  regardless  of  the  organizational  structure.  Similar  to  most  intelligence  organizations, 
the  key  processes  performed  within  ONl-2  are  directly  related  to  the  basic  processes 
performed  in  the  generic  intelligence  process  known  as  the  intelligence  cycle.  The 
intelligence  cycle  refers  to  the  sequence  of  steps  or  phases  by  which  data  is  gathered  and 
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TABLE  4:  ONI  MARITIME  INTELLIGENCE  ROLES  [Ref.  ll:p.  15] 


Combat  Support 

Planning,  Programming,  Budgeting 

Indications  and  Warning 

Counterintelligence  and  Security 

Special  Operations 

Counterterrorism 

Special  Maritime  Collection 

Counterdrug 

Tactical  Analysis 

Nuclear  Proliferation  Control 

Threat  and  Opportunities  Analysis 

Treat  Verification  and  Arms  Control 

Tactics  Development  and  Evaluation 

Strategic  Trade  and  Economic  Intel 

Training  -  Combat 

Multilateral  Agreements 

Training  -  Military  and  Civilian 

Intelligence  Estimates 

Training  -  Professional  Development 

Ocean  Services  and  Resources 

RDT  &  E  and  Acquisition 

Ocean  Environment 

transformed  into  meaningful  information  that  is  then  made  available  to  users  or  consumers. 
This  cycle  consists  of  three  key  processes:  (1)  collection,  (2)  production,  and  (3) 
dissemination. 

The  collection  phase  deals  with  the  planning  and  preparation  required  for 
obtaining  and  forwarding  selected  data  and  information  about  a  specific  objective.  Its  focus 
is  the  acquisition  of  data  for  further  processing.  During  the  collection  phase,  decisions 
regarding  the  selection,  allocation,  and  use  of  operational  and  intelligence  sources  are  made 
to  obtain  the  required  information.  Collection  provides  the  essential  data  for  the  intelligence 
process.  The  data  derived  in  the  collection  phase  is  evaluated  in  the  production  phase. 

The  production  phase  involves  the  conversion  of  collected  data  into  a  form 
suitable  for  the  user.  This  conversion  process  involves  manipulating  the  collected  data 
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through  integration,  analysis,  evaluation,  and  interpretation  into  an  intelligence  product. 
This  process  of  converting  collected  data  into  an  intelligence  product  is  the  primary  process 
common  to  all  work  groups  within  ONl-2  regardless  of  mission  area.  The  analysis 
performed  at  the  production  phase  is  the  key  business  function  of  the  organization  and 
requires  direct  support  from  automated  information  systems  and  their  applications.  “The 
intelligence  analyst,  working  with  raw  information  collected  from  a  variety  of  sources, 
selects,  verifies,  compares,  infers,  interprets,  and  acts  upon  available  information  and 
intelligence  to  produce  a  usable  end  product.”  [Ref.  21  :p.  7-1] 

The  final  phase  in  the  intelligence  cycle  is  dissemination  of  the  refined 
intelligence  product  or  service.  This  phase  specifically  involves  the  conveyance  of  the 
intelligence  product  or  service  to  the  consumer  or  user.  It  is  pointless  to  collect  data  and  to 
process  it  into  meaningful  intelligence  if  it  does  not  reach  the  proper  consumer  at  the  proper 
time.  Dissemination  can  take  on  many  forms.  It  covers  a  broad  spectrum  ranging  from  a 
brief  telephone  response  to  the  transfer  of  large  volumes  of  detailed  and  comprehensive 
intelligence  documents.  Effective  intelligence  dissemination  requires  (1)  that  the  consumers 
having  the  need  to  know  receive  the  information,  (2)  that  delivery  of  the  information  is 
timely,  and  (3)  that  the  information  reaches  the  consumer  in  an  appropriate  form. 
Automated  information  systems  have  significantly  impacted  the  means  of  dissemination  and 
provide  direct  transmission  of  the  information  to  the  end  user.  [Ref.  21:p.  8-1] 

The  key  processes  in  the  intelligence  cycle  are  commonly  performed  within  each 
ONI-2  department  regardless  of  the  analytical  focus  of  the  work  group  or  division.  Each 
intelligence  product  or  service  can  usually  be  traced  back  to  its  origin  through  the  individual 
phases  in  the  cycle.  As  a  whole,  however,  the  cycle  can  be  viewed  as  having  no  beginning 
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or  end  point.  Instead,  the  intelligence  cycle  is  an  ongoing  series  of  key  processes  with  all 
the  steps  typically  occurring  concurrently. 

C.  INFORMATION  VIEW 

The  information  view  of  the  current  architecture  is  intended  to  provide  a  high-level 

understanding  of  the  information  needed  to  perform  the  work  of  the  enterprise.  The 
information  view  focuses  on  the  data  being  managed  in  support  of  work  groups  and 
external  customers.  Models  provide  an  understanding  of  the  relationships  with  customers 
and  the  mission  critical  data  flows  to  and  from  the  customers.  As  stated  in  the  ONI 
Strategic  Planning  document,  “The  essence  of  our  excellence  lies  in  this  synergy  of  human 
and  technical  resources  and  in  the  application  of  naval  expertise  to  convert  data  to 
information.”  [Ref.  ll:p.  11] 

1.  Organizational  Relationships 

The  business  functions  performed  by  ONI-2  are  in  direct  response  and  support 
to  ONI’s  broad  customer  base.  Analysis  of  intelligence  relationships  with  these  external 
customers  will  reveal  additional  capability  requirements  and  provides  insight  regarding  the 
performance  of  the  formally  defined  missions.  These  organizational  relationships  are  often 
not  defined  formally,  and  must  be  identified  and  recorded  as  part  of  the  architectural  effort. 
The  DODnS  architectural  guidance  provides  a  one-page  summary  chart  for  recording  these 
relationships. 
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Figure  9:  ONI’s  Organizational  Site  Relationships 


Figure  9  shows  the  general  relationships  with  OKI’s  primary  customers  with 
tasking,  evaluation,  and  support  relationships  depicted  between  sites.  The  example. 
Figure  9,  shows  the  following: 


Guidance  from  the  National  Command  Authority  (NCA),  Congress,  and  the 
Office  of  the  Secretary  of  Defense  (OSD)  concerning  organization,  funding,  and 
responsibilities  with  intelligence  support  provided  to  key  decision  makers. 


•  Intelligence  support  provided  directly  to  naval  forces  with  additional  collection 
requirements  established.  This  includes  direct  support  to  fleet  intelligence 
officers  (FLT  N2s  and  components  of  the  Fleet  Marine  Forces  (FMF). 

•  Cooperative  agreements  with  law  enforcement  agencies  to  exchange  information 
related  to  seaborne  transfers  of  illegal  cargoes.  Agencies  include  the  Drug 
Enforcement  Agency  (DEA),  the  Federal  Bureau  of  Investigation  (FBI),  and 
U.S.  Customs  Agency. 

•  Intelligence  support  provided  to  treaty  organizations  related  to  international 
agreements  such  as  arms  control  or  sanctions  enforcement,  including  the  United 
Nations  and  the  North  Atlantic  Treaty  Organization  (NATO). 

•  Requests  for  information  from  organizations  involved  in  weapons  and  defense 
systems  acquisition  and  evaluations  such  as  program  executive  officers  (PEOs), 
research  laboratories  such  as  the  Naval  Research  Laboratory  (NRL),  and 
weapons  testing  entities  such  as  the  Navy’s  Operational  Test  and  Evaluation 
Force  (OPTEVFOR). 

•  Analysis  and  support  provided  to  educational  and  training  commands  such  as  the 
Naval  War  College  (NAVWARCOL),  the  Naval  Postgraduate  School  (NPS), 
and  the  U.S.  Naval  Academy  (USNA).  Analysis  and  wargaming  efforts  of 
these  units  provide  ONI  with  additional  analytical  intelligence  support. 

•  Intelligence  exchanges  and  analysis  efforts  with  other  intelligence  organizations 
such  as  the  Central  Intelligence  Agency  (CIA),  the  National  Security  Agency 
(NSA),  and  the  Defense  Intelligence  (DIA)  for  example. 
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•  A  primary  customer,  the  Unified  and  Specified  Commands  with  their  Joint  Task 
Forces  and  the  supporting  Joint  Intelligence  Centers  (JICs)  that  establishes 
intelligence  requirements  through  requests  for  information  and  are  provided  with 
direct  intelligence  support  from  ONI. 

2.  External  Data  Flows 

The  final  area  of  analysis  for  presenting  the  work  organization  view  is  external 

data  flow  analysis.  Data  flow  analysis  will  indicate  support  to  other  sites  that  is  not 
necessarily  mission-specific.  It  also  identifies  required  capabilities  to  accept  data  from 
other  sites.  Similar  to  the  one-page  chart  used  to  summarize  external  relationships,  Figure 
10  summarizes  the  data  flows  using  the  DODIIS  architectural  guidelines.  The  format  is  the 
same  as  the  organizational  chart,  except  that  the  arrow  notations  are  used  to  indicate 
example  data  information  flows  instead  of  relationships.  For  example.  Figure  10  shows 
the  type  or  form  of  data  transfered  between  sites  such  as: 

•  Intelligence  estimates  provided  to  national-level  consumers. 

•  Threat  assessments  provided  to  naval  operational  forces. 

»  Counter-Drug  products  exchanged  with  law  enforcement  agencies. 

•  Arms  transfer  data  provided  to  treaty  organizations. 

•  Specific  weapons  performance  data  provided  to  the  research  and  acquisition 
community. 

•  Platform  capability  and  characteristics  data  supporting  education  and  training. 

•  Sensor  data,  such  as  Signals  Intelligence  (SIGINT),  received  from  other 
intelligence  agencies. 
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And,  requests  for  information  received  from  the  major  joint  commands  that  are 
then  provided  with  specific  targeting  data,  for  example. 


The  organizational  site  relationships  and  corresponding  data  flows  can  take  on 
many  different  forms,  with  only  a  few  mentioned  here.  These  relationships  are  depicted  to 
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characterize  the  type  of  information  exchanges  that  must  be  supported  by  the  intelligence 
applications  within  an  automated  information  system.  The  processes  involved  with  each 
relationship  rely  on  information  systems  and  specific  applications  with  unique 
functionality.  These  applications  will  be  discussed  in  the  application  view  of  this  baseline 
characterization. 

D.  APPLICATION  VIEW 

The  application  view  of  the  baseline  describes  the  current  applications,  systems,  and 
databases  that  directly  support  the  mission-critical  functions  described  in  the  work  and 
information  views.  This  view  describes  the  high-level  scope  and  interfaces  among 
applications.  The  applications  are  described  in  terms  of  functionality  and  technical  system 
components  required.  These  systems  currently  support  intelligence  analysts  within  the 
Intelligence  Directorate  (ONI-2). 

1.  Automated  Merchant  Identification  Ship  System 
(AMIDSHIPS) 

Functional  Description:  The  AMIDSHIPS  system  provides  automated 
capabilities  for  accessing  ONI’s  civil  maritime  database  of  approximately  500,000  merchant 
ship  photographs,  plans,  and  drawings.  It  provides  capability  to  input  and  annotate 
softcopy  images  which  are  stored  on  optical  disks.  It  supports  analyst  database  retrieval 
based  on  known  ship  characteristics.  The  images  are  identified  by  matching  characteristics 
using  a  subset  of  the  Naval  Intelligence  Database  (NED)  containing  Merchant  Ship 
Characteristics  (MSC)  data. 
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System  Components:  AMIDSHIPS  is  a  workstation  network  based  system 
hosted  on  SUN  workstations  including  SUN  4/690  (server),  4/670  (server),  4/370,  and 
Sparc  2.  The  operating  system  is  SUN  OS  4.1.4.  The  AMIDSHIPS  application  software 
is  contractor  developed  with  Sybase  DBMS. 

2.  Collection  Requirements  Management  Application 
(CRMA) 

Functional  Description:  The  CRMA  system  provides  automated  capabilities  for 
centralized  management  of  intelligence  collection  requirements,  resulting  products,  and 
evaluations  of  Intelligence  Information  Reports  (HR)  from  DIA  and  the  Navy.  It  provides 
tools  to  model  collection  systems,  manage  tasking  requirements,  predict  availability  of 
assets,  and  to  store  and  recall  reference  data.  The  CRMA  is  a  DODIIS  core  product. 

System  Components:  CRMA  is  a  network  based  system  hosted  on  workstations 
including  SUN  4/690  (server),  SUN  Sparc  2,  SUN  Sparc  10,  and  TAC-3.  The  operating 
system  is  SUN  OS  4.1.3.  The  CRMA  application  software  is  government  developed  with 
Sybase  DBMS. 

3.  Joint  Maritime  Information  Element  (JMIE) 

Functional  Description:  The  JMIE  system  provides  a  composite,  multi-agency 
library  of  maritime  data  from  multiple  sources  including  open  source,  national  foreign 
intelligence,  and  law  enforcement  agencies.  Information  on  merchant  shipping  includes 
movement  data,  ship  characteristics,  port  data,  and  organizational  information.  Seventeen 
U.S.  Government  agencies  operate  JMIE  workstations  at  33  different  sites  worldwide. 

System  Components:  JMIE  is  a  PC  workstation-based  system  connected  via 
DSNETl  or  commercial  phone  lines  (STU-III)  to  an  IBM  4381  mainframe  host  located  at 
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the  U.S.  Coast  Guard  Operations  Center  in  Martinsburg,  West  Virginia.  The  JMIE 
database  interfaces  with  SeaWatch  ID  and  the  Merchant  Ship  Characteristics  (MSC) 
Database. 

4.  Merchant  Ship  Characteristics  (MSC)  Database 

Functional  Description:  The  MSC  Database  provides  automated  capability  for 
the  analysis  of  merchant  ship  characteristics  throughout  the  life  of  the  vessel  in  support  of 
civil  maritime  analysis.  It  provides  data  base  management  capabilities  for  storage  and 
retrieval  of  characteristics  and  performance  data  on  merchant  ships  such  as  length,  speed, 
displacement,  etc.  The  MSC  Database  provides  baseline  data  to  several  other  systems 
directly  or  via  magnetic  tape  including  SeaWatch  ID,  Naval  Intelligence  Database  (NID), 
the  Joint  Maritime  Information  Element  (JMIE),  and  AMIDSHIPS. 

System  Components:  The  MSC  Database  is  hosted  on  a  VAX  6410  supporting  a 
network  of  approximately  62  PCs.  The  operating  systems  are  VAX  VMS  5.5  and  MS- 
DOS.  The  MSC  application  software  is  contractor  developed  (MSC  1.0)  with  Oracle  6.0 
DBMS. 

5.  Merchant  Watch  (MerWatch) 

Functional  Description:  The  MerWatch  system  provides  tools  supporting  civil 
maritime  analysis.  This  includes  tools  to  generate  merchant  shipping  related  intelligence 
products  with  information  on  ports,  cargo,  ship  movement,  and  organizations.  The 
MerWatch  software  architecture  represents  a  deliberate  attempt  to  integrate  existing  civil 
maritime  analysis  functionality  and  databases  into  a  single  DODlIS-compliant  system. 
MerWatch  interfaces  with  the  SeaWatch,  MSC,  and  AMIDSHIPS  databases. 
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System  Components:  MerWatch  is  a  network-based  system  hosted  on 
workstations  including  SUN  690MP  (server),  SUN  Sparc  10  (42),  SUN  IPX  (4).  The 
operating  system  is  SUN  OS  4.1.3.  The  MerWatch  application  software  is  government 
developed  (MerWatch  D)  with  supporting  commercial  applications  including  Aster*x  2. 1 
AND  ELT/2000  2.3.  Oracle  6.0  is  the  DBMS. 

6.  Naval  Intelligence  Database  (NID) 

Functional  Description:  The  NID  provides  automated  capability  for  analysis  of 
performance  and  characteristics  data  on  threat  platforms  and  the  production  of  threat 
assessments  and  other  publications.  It  also  rovides  database  management  capabilities  for 
storing,  retrieving,  and  analyzing  threat  characteristics  data.  The  NID  incorporates  the 
MSC  database. 

System  Components;  The  NID  is  hosted  on  a  DEC  ALPHA  7610  supporting 
various  workstations  including  SUN,  HP,  MAC,  PCs.  The  operating  system  is 
Open  VMS.  The  NED  application  software  is  contractor  developed  (NID  2.0)  with  Oracle 
7.0  DBMS. 

7.  SeaView 

Functional  Description:  The  SeaView  system  provides  analysts  with  state-of- 
the-art  tools  to  create  intelligence  products  by  accessing,  manipulating,  and  graphically 
displaying  ocean  surveElance  information  (from  the  SeaWatch  IE  database).  It  provides 
capabilities  to  retrieve,  sort,  manipulate,  and  compare  information  from  various  data  bases, 
as  well  as  create  colored  maps  and  graphical  displays  with  multi-dimensional  views  of  the 
data. 
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System  Components:  SeaView  is  a  network-based  system  hosted  on 
approximately  30  workstations  including  the  SUN  4  Sparc  family.  The  operating  system  is 
SUN  OS  4.1.3.  The  SeaView  application  software  is  contractor  developed  with 
SeaView/Sunshine  5.0.2.  providing  access  to  several  external  databases  via  DSNET3,  in 
addition  to  SeaWatch  III  access. 

8.  SeaWatch  III 

Functional  Description:  The  SeaWatch  III  system  serves  as  ONI’s  central  data 
processing  system  for  ocean  surveillance  data.  It  provides  automated  capability  to  store, 
retrieve,  and  disseminate  ocean  surveillance  data  in  support  to  civil  maritime  analysis.  The 
database  supports  several  applications  and  is  support  by  the  MSC  database.  The  system 
receives  reporting  data  from  various  sources.  Primary  capabilities  and  functions  include 
message  format  input  and  output  processing,  automatic  track  correlation  and  association, 
data  retrieval  and  manipulation,  and  a  wide  range  of  analytical,  service,  and  administrative 
tools. 

Capable  of  processing  inputs  from  multiple  data  sources,  SeaWatch  receives  an 
approximately  40,000  ship  position  reports  per  day.  Over  four  million  position  reports  are 
stored  per  year.  SeaWatch  constitutes  the  sole  national  resource  for  current  and  archival 
storage  of  merchant  ship  movement  reports  as  well  as  the  national  archive  for  threat  naval 
fleet  movement  data. 

System  Components:  SeaWatch  III  is  hosted  on  an  IBM  3090  mainframe 
processor  and  Model  204  (v  2.2)  database.  It  provides  on-line  support  to  over  100 
analysts  on  both  SUN  4  series  workstations  and  PCs.  The  operating  systems  include  the 
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MVS/XA,  SUN  OS  4.1.1,  and  MS-DOS.  The  SeaWatch  HI  application  software  (v  1.5) 
is  contractor  developed. 

E.  TECHNOLOGY  VIEW 

1.  General  Description 

The  technology  view  of  the  current  baseline  architecture  provides  a  general 
description  of  the  major  components  of  the  computer  processing  and  communications 
environment.  The  ONI  Local  Area  Network  (LAN)  system  is  complex  and  serves  over 
2,000  intelligence  analysts  and  support  personnel.  The  system  has  grown  over  the  years 
from  a  variety  of  self-contained,  largely  single-function  users  with  their  own  separate  and 
isolated  LAN  systems  in  two  separate  buildings,  to  a  large  complex  of  networked 
intelligence  analysts  and  support  personnel  on  a  single,  very  large  system  located  in  a 
modem  facility  known  as  the  National  Maritime  Intelligence  Center  (NMIC).  The  NMIC 
building  is  equipped  with  a  Fiber  Distributed  Data  Interface  (FDDI)  backbone  supporting 
two  primary  internal  network  systems,  the  General  Service  (GENSER)  LAN  system,  and 
the  Sensitive  Compartmented  Information  (SCI)  LAN  system.  The  NMIC  is  configured 
with  fiber  optic  cabling  to  support  these  LAN  systems.  Ethernet  (Transmission  Control 
Protocol/Intemet  Protocol  -  TCP/IP)  connectivity  is  provided  to  the  backbone  supporting 
the  various  systems  and  workgroup  requirements. 

2.  General  Service  (GENSER)  System 

The  General  Services  (GENSER)  LAN  System,  which  is  used  for  transmission 
and  receipt  of  collaterally  classified  information  (i.e..  Confidential  and  Secret  data),  is 
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composed  of  the  Joint  Message  Processing  System  (IMPS),  a  Vax-based  host  system 
which  supports  GENSER-level  message  and  data  traffic  flow,  and  an  Ethernet  LAN 
system  which  supports  OKI’s  requirements  to  have  GENSER  message  traffic  available  to 
the  analyst  workstations  from  both  the  Automatic  Digital  Network  (AUTODIN)  and  the 
Defense  Secure  Network  (DSNETl).  The  GENSER  LAN  system  supports  the 
AMIDSHIPS  and  JMIE  systems  and  the  MSC  database. 

3.  Sensitive  Compartmented  Information  (SCI)  System 

The  Sensitive  Compartmented  Information  (SCI)  LAN  system  supports  the 

requirements  for  transmission  and  receipt  of  more  highly  classified  information.  The  SCI 
LAN  system  supports  the  AMIDSHIPS,  CRMA,  MerWatch,  SeaView,  SeaWatch  III 
systems  and  NID  database.  The  SCI  LAN  provides  analysts  access  to  the  Defense  Secure 
Network  (DSNET3). 

4.  The  SeaWatch  III  System 

The  SeaWatch  III  system  is  an  IBM  mainframe-based  system  interfaced  to  the 
backbone  via  to  the  Ethernet  network.  The  system  retains  its  IBM  Systems  Network 
Architecture  (SNA)  and  uses  converters  to  interface  the  IBM  mainframe  (an  IBM  3090)  to 
the  Ethernet  network  segment.  The  Seawatch  III  system  has  approximately  20  SUN 
workstations  for  analyst  access,  with  many  others  gaining  limited  functionality  access  on 
PCs.  Approximately  130  analysts  have  access  to  the  system;  however,  there  are  generally 
no  more  than  20  to  25  people  on  the  system  at  any  one  time.  [Ref  22:p.  8] 
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5.  Automated  Message  Handling  System  (AMHS) 

The  current  ONI  Automated  Message  Handling  System  (AMHS)  is  designed  to 
automatically  receive  and  distribute  incoming  record  message  traffic  to  the  users’ 
workstations  and  to  transmit  via  AUTODIN. 
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V.  THE  TARGET  ARCHITECTURE 


A.  INTRODUCTION 

This  chapter  presents  a  target  architecture  to  guide  systems  development  and  evolution 
at  ONI.  This  chapter  specifically  addresses  the  Joint  Maritime  Command  Infonnation 
System  (JMCIS)  architecture.  A  thorough  understanding  of  the  JMCIS  architecture  is 
essential  to  guide  the  architecture  development  efforts  at  ONI.  As  the  current  state  of  US 
Navy  C4I  systems,  JMCIS  represents  a  systems  architecture  that  has  evolved  over  the  last 
decade,  incorporating  the  functionality  and  objectives  of  multiple  systems.  This  chapter 
presents  this  evolution  to  provide  a  background  understanding  of  the  current  architecture. 
Finally,  this  chapter  will  present  the  specific  application  of  the  JMCIS  architecture  concepts 
to  ONI  system  requirements  and  ongoing  development  efforts. 

B.  EVOLUTION  OF  U.S.  NAVY  C4I  SYSTEMS 
ARCHITECTURE 

1.  Joint  Operational  Tactical  System  (JOTS) 

The  Joint  Operational  Tactical  System  (JOTS)  began  as  a  prototyping  effort  that 
was  first  deployed  aboard  ship  in  the  early  1980s.  This  system  provided  the  operational 
commander  with  the  first  integrated  display  of  data  for  decision  support  purposes.  System 
functionality  eventually  included  track  management,  track  analysis,  environment  prediction, 
and  a  variety  of  tactical  overlays  and  Tactical  Decision  Aids  (TDAs).  JOTS  was  capable  of 
receiving  various  data  and  message  input  such  as  Link  1 1,  Link  14,  Tactical  Data 
Information  Exchange  System  (TADIXS-A),  Officer-in-Tactical-Command  Information 
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Exchange  System  (OTCIXS),  High  Interest  Track  (HIT)  Broadcasts,  and  U.S.  Message 
Text  Format  (USMTF)  messages.  JOTS  allowed  the  Fleet  Command  Centers  to  interface 
with  command  ships  and  other  shore  installations.  Through  the  use  of  a  tactical  database 
manager  (TDBM),  JOTS  provided  a  consistent  tactical  battlespace  picture  for  all  supporting 
warfare  commanders  afloat  and  ashore.  [Ref.  17:p.  60] 

The  original  prototyping  effort  of  JOTS  led  to  the  development  of  the  JOTS 
Command  and  Control  System  by  the  late  1980s.  The  primary  goal  of  JOTS  was  to 
integrate  information  systems  onto  common  hardware  and  software  platforms  to  allow  the 
sharing  of  databases  as  well  as  maximize  limited  shipboard  space.  JOTS-derived  systems 
have  since  been  installed  onboard  over  200  Navy  ships,  at  several  US  Navy  shore 
intelligence  centers,  onboard  US  Coast  Guard  vessels  and  allied  ships,  and  at  various  allied 
shore  facilities.  As  JOTS  matured  further  and  as  other  C3I  systems  were  developed  and 
deployed,  it  became  apparent  that  there  was  much  duplication  of  software  and  functionality 
across  systems.  This  duplication  led  to  increased  development,  maintenance,  and  training 
costs  and  the  goal  of  interoperability  across  systems  was  virtually  non-existent.  This  low 
degree  of  interoperability  led  to  conflicting  information  from  multiple  sources  being  provide 
to  the  operators  and  afloat  decision  makers.  [Ref.  23:p.  1-1] 

2.  Navy  Tactical  Command  System  -  Afloat  (NTCS-A) 

The  Navy  Tactical  Command  System  -  Afloat  (NTCS-A)  evolved  from  JOTS  in 
the  early  1990s  from  the  consolidation  of  a  number  of  prototypes  of  individual  "stovepipe" 
shipboard  command  and  control  software  programs,  including  the  Flag  Data  Display 
System  (FDDS),  the  Joint  Operations  Tactical  System  (JOTS),  the  Electronic  Warfare 
Coordination  Module  (EWCM),  and  the  Afloat  Correlation  System  (ACS)  [Ref.  15:p.  52]. 
Additional  NTCS-A  functionality  was  incorporated  from  other  stand-alone  or  prototype 
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C4I  systems  such  as  the  Prototype  Ocean  Surveillance  Terminal  (POST)  and  the  Naval 
Intelligence  Processing  System  (NIPS).  Central  to  this  consolidation  effort  was  the 
abstraction  of  the  afloat  software  into  a  common  "core"  set  of  software  that  could  be  used 
throughout  the  afloat  community  as  the  basis  for  their  systems.  This  led  to  a  set  of 
common  software  originally  called  GOTS  version  1.1. 

TTie  common  core  software  concept  was  extended  to  the  shore  community  to 
reduce  development  costs  and  ensure  interoperability.  This  effort  resulted  in  a  collection  of 
software  commonly  referred  to  as  the  Unified  Build  (UB)  version  2.0  or  GOTS  2.0.  This 
software  is  now  deployed  both  afloat,  in  NTCS-A,  and  ashore,  in  Operations  Support 
System  (OSS)  known  also  as  Navy  Command  and  Control  System- Ashore  (NCCS-A). 
The  strength  of  these  two  systems  is  that  they  are  built  on  top  of  a  common  set  of  functions 
so  that  advancements  and  improvements  in  one  area  are  immediately  translatable  to 
advancements  in  the  other  area.  [Ref.  23  :p.  1-1] 

3.  Operations  Support  System  (OSS) 

The  Operations  Support  System  (OSS)  evolved  from  the  functionalities  of  the 
Navy  World-Wide  Military  Command  and  Control  System  (WWMCCS)  Standard 
Software,  Operations  Support  Group  Prototype,  Fleet  Command  Center  Battle 
Management  Program,  and  JOTS.  This  system  is  considered  the  shore  installation  variant 
of  NTCS-A  and  is  often  referred  to  as  Navy  Command  and  Control  System-Ashore 
(NCCS-A).  By  migrating  the  OSS  into  the  JMCIS  architecture,  the  Navy  is  seeking 
management  economies  of  scale  and  performance  enhancements  in  OSS. 

4.  Joint  Maritime  Command  Information  System  (JMCIS) 

The  Joint  Maritime  Command  Information  System  (JMCIS)  represents  the  next 
logical  step  in  the  evolution  of  Navy  C4I  systems.  The  addition  of  functions  to  NTCS-A 
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has  led  to  the  creation  of  a  new  version  of  that  system,  which  has  been  designated  JMCIS. 
JMCIS  is  described  as  a  "overarching  architecture"  that  is  still  evolving  as  fleet  operators 
refine  C4I  requirements  and  the  functionality  of  other  systems  is  migrated  to  the  JMCIS 
architecture.  The  JMCIS  approach  to  adding  new  functionality  instead  of  building  new 
systems  allows  the  Navy  to  benefit  from  a  single-configuration  management  approach. 

The  system  software  provides  the  basic  functions,  such  as  display  control,  message-traffic 
control,  and  specific  applications  for  various  ship  classes.  [Ref.  15:p.  56] 

Programmatically,  JMCIS  has  consolidated  the  functions  of  NTCS-A  and  its 
complimentary  ashore  program,  the  OSS.  The  two  systems  are  expected  to  form  a 
significant  core  of  the  ongoing  development  of  service-wide  C4I  architectures,  referred  to 
as  the  Global  Command  and  Control  System  (GCCS),  that  will  continue  to  consolidate  the 
C4I  initiatives  of  the  individual  services.  [Ref.  15;p.  56] 

5.  Global  Command  and  Control  System  (GCCS) 

GCCS  is  a  Joint  Staff  sponsored  program  envisioned  by  the  C4I  for  the  Warrior 
concept  and  represents  the  next  step  in  the  evolution  of  command  and  control  systems. 
When  fully  implemented,  GCCS  will  embody  a  network  of  systems  providing  the  Warrior 
with  a  full  complement  of  command  and  control  capabilities.  As  part  of  the  C4I  for  the 
Warrior  concept,  GCCS  is  evolving  into  a  global,  seamless  "Infosphere"  capable  of 
meeting  the  Warrior's  fused  information  requirements.  [Ref.  18:p.  25] 
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JMCIS  Architectural  Evolution 

PRE  1993  1993  1994  1995  1996  1997 


6.  Systems  Migration 

The  proceeding  description  of  the  Navy  C4I  systems  evolution  focused  primarily 
on  the  core  systems  only.  In  addition  to  the  primary  systems  described,  several  other 
systems  have  merged  functionahty  into  these  core  C4I  systems  as  the  evolution  progressed. 
Figure  1 1  shows  the  various  systems  that  have  “migrated”  toward  the  core  environment 
that  is  currently  the  JMCIS  architecture.  Note  the  pre-1993  systems  that  represent  a  myriad 
of  functionality  that  integrated  into  follow-on  systems.  The  current  status  of  the  evolution 
is  JMCIS.  However,  this  evolution  will  continue,  adding  the  additional  functionality  of 
both  traditional  C4I  systems  as  well  as  administrative  support  systems  such  as  the 
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Shipboard  Non-Tactical  ADP  System  (SNAP).  Table  5  provides  a  listing  of  full  names  for 
the  systems  that  have  been  or  are  scheduled  to  be  migrated  to  the  JMCIS  architecture. 


TABLE  5:  MIGRATION  SYSTEMS 


Acronym 

Full  System  Name 

ACS 

Afloat  Correlation  System 

ATP 

Advanced  Tracking  Prototype 

BGPHES 

Battle  Group  Passive  Horizon  Extension  System 

CCSC 

Cryptologic  Combat  Support  Console 

ccss 

Cryptologic  Combat  Support  System 

CID/CIU 

Cryptologic  Interface  DeviceAJnit 

EWCM 

Electronic  Warfare  Coordination 

FHLT 

Force  High  Level  System 

JOTS 

Joint  Operational  Tactical  System 

MRMS 

Maintenance  Resource  Management  System 

NALCOMS 

Navy  Aviation  Logistics  Command  Management  Information  System 

NAVSSI 

Navigation  Sensor  System  Interface 

NIPS 

Naval  Intelligence  Processing  System 

MITES 

NTCS-A  Integrated  Tactical  Environmental  Subsystem 

NTCS-A 

Navy  Tactical  Command  System  -  Afloat 

NTCSS 

Navy  Tactical  Command  Support  System 

NWSS 

Navy  WWMCCS  Software  Standardization 

OBU/OED 

Ocean  Surveillance  Information  System  (OSIS)  Baseline  Upgrade 

OSS 

Operations  Support  System 

POST 

Prototype  Ocean  Surveillance  Terminal 

SNAP 

Shipboard  Non-Tactical  ADP  Program 

SSEE 

Ships  Signal  Exploitation 

STT 

Shore  Targeting  System 

TFCC 

Tactical  Flag  Command  Center 

TSC 

Tactical  Support  Center 
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C.  THE  JOINT  MARITIME  COMMAND  INFORMATION 
SYSTEM  (JMCIS)  ARCHITECTURE 


I.  Description 

The  Joint  Maritime  Command  Information  System  (JMCIS)  is  built  as  an 
architectural  framework  to  meet  specific  Navy  and  DoD  command  and  control  (C2) 
capabilities.  Similar  to  the  Microsoft  Windows  environment,  JMCIS  provides  an 
environment  for  applications  to  consolidate  common  functions.  In  Microsoft  Windows, 
multiple  applications  share  common  utilities  such  as  printing  and  file  management,  rather 
than  duplicating  those  functions  for  each  application.  For  C2  systems,  JMCIS  provides 
various  common  utilities  such  as  mapping  and  tactical  database  display  functions  among 
others.  This  collection  of  utilities  comprises  the  JMCIS  core  which  is  maintained  and 
expanded  based  upon  the  migration  of  legacy  systems  and  improvements  to  existing 
JMCIS  applications. 

JMCIS  is  designed  to  be  an  open  system  that  enables  true  functional  integration 
through  standard  display,  data,  and  communications  management.  JMCIS  offers  an 
"integration  of  systems"  versus  "federation  of  systems."  That  is,  it  is  not  sufficient  for  two 
applications  to  execute  on  the  same  hardware  and  be  simultaneously  available  to  an 
operator.  In  addition  to  sharing  common  utilities,  the  applications  must  also  share  data. 
This  approach  represents  a  key  difference  between  the  JMCIS  approach  and  the  Microsoft 
Windows  environment.  [Ref  23:p.  1-11] 

The  consolidation  of  functions  into  a  Common  Operating  Environment  (COE) 
allows  all  applications  to  access  the  most  efficient  utility  and  provides  the  opportunity  to 
easily  update  the  core  utilities  with  improved  versions.  In  traditional  client/server  style, 
JMCIS  servers  provide  core  services  to  the  rest  of  the  network  and  each  workstation  may 


90 


have  either  the  same  or  different  application  software  mnning.  Figure  12  shows  the 
JMCIS  software  architecture.  Various  applications  can  be  selected  to  run  “on  top”  of  the 
COE.  Those  applications  may  have  originally  served  as  the  base  functionality  for  a 
previous  Navy,  Marine  Corps,  or  other  service’s  stand-alone  application.  [Ref.  23;pp.  1-3] 


JMCIS  is  an  umbrella  system  that  has  incorporated  various  functionalities  and 
attributes  of  previous  command  and  control  systems.  The  philosophy  of  incorporating 
other  systems  capabilities  and  functionality  is  not  unique  to  JMCIS;  rather,  it  is  a  trait 
inherited  from  previous  systems.  The  Joint  Operational  Tactical  System  (JOTS),  Navy 
Tactical  Command  System  -  Afloat  (NTCS-A),  and  Operations  Support  System  (OSS)  are 
examples  of  systems  that  applied  this  same  evolutionary  methodology  and  directly 
influenced  the  development  of  JMCIS.  The  core  software  GOTS  1 . 1  was  compiled  for  use 
throughout  the  afloat  community  as  the  basis  for  all  C4I  systems.  GOTS  2.0  was  called 
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the  Unified  Build  (UB)  2.0  and  was  developed  to  include  the  ashore  community  in  order  to 
further  increase  system  interoperability.  The  system  was  also  designed  to  operate  on  the 
Tactical  Advanced  Computing  (TAG)  family  of  computers,  as  a  non-proprietary,  open 
architecture  that  could  be  easily  transported  to  subsequent  improved  versions  of  the  TAC. 
[Ref.  23:pp.  1-3] 

2.  System  Software  Components 

The  heart  of  JMCIS  is  the  collection  of  software  components.  JMCIS  should  be 
viewed  as  a  collection  of  several  related  items  required  for  developing  an  information 
system.  JMCIS  provides  a  clearly  defined  set  of  functions  or  modules  which  constitute  a 
C4I  system.  These  functions  and  the  software  which  implements  them  form  the  JMCIS 
core  services  and  include  track  management,  correlation,  communications,  and  tactical 
display  components.  Additionally,  JMCIS  provides  a  precisely  defined  architecture  for 
how  the  modules  will  interact  and  fit  together. 

a.  Common  Operating  Environment  (COE) 

The  JMCIS  Common  Operating  Environment  (COE)  consists  of  the  UNIX 
Operating  System  (OS),  X-Windows  graphical  windowing  system,  and  Motif  standard 
styles.  In  addition  to  the  COTS  software,  the  JMCIS  COE  provides  core  software  for 
receiving  and  processing  messages,  correlation,  updating  the  track  database,  and  software 
for  generating  displays.  The  JMCIS  COE  provides  for  unattended  message  reception, 
processing,  and  track  management  so  that  an  operator  need  not  actually  be  logged  in  to  a 
workstation.  [Ref.  23 :p.  2-1] 
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b.  Unified  Build  (UB) 


The  Unified  Build  (UB)  is  the  foundation  for  all  JMCIS  software.  The  UB  is  a 
set  of  software  components  that  include  the  Common  Operating  Environment  (COE)  and  a 
standard  software  base  for  central  applications  and  library  functions  necessary  for  basic- 
command,  control,  and  supporting  functions.  The  UB  is  not  a  deliverable  system  by  itself, 
but  is  delivered  to  developers  for  use  in  building  an  end  system. 
c.  JMCIS  Segments 

A  segment  is  a  software  application  that  operates  in  the  JMCIS  environment 
utilizing  core  functionalities  for  common  operations.  Segments  access  the  core 
functionality  through  a  standard  set  of  Application  Program  Interfaces  (APIs).  The 
standard  set  of  APIs  is  managed  by  the  core  developers  and  is  the  access  vehicle  to  core 
functionality.  Unique  functionality  for  individual  segments  is  provided  by  the  individual 
applications’  source  executable  code.  JMCIS  segments  provide  a  collection  of  already 
developed  and  tested  Tactical  Decision  Aids  (TDAs)  and  support  functions  (range  and 
bearing  calculations,  CPA,  etc.)  that  may  be  incorporated  into  a  particular  JMCIS  variant. 

There  are  different  types  of  JMCIS  segments  depending  on  the  level  of 
integration  and  the  functionality  required  by  the  segment.  Most  JMCIS  developers  will  be 
creating  software  segments  that  represent  options  to  add  to  the  JMCIS  core  functionality. 

As  previously  described,  software  segments  access  the  JMCIS  core  services  through  APIs. 
Likewise,  data  segments  allow  data  files  to  be  treated  just  like  any  other  JMCIS  segment, 
each  loaded  individually.  [Ref.  23  :p.  3-7] 

The  functionaUty  of  many  previous  stand-alone  systems  have  been  integrated 
into  current  JMCIS  segments.  Figure  13  depicts  many  of  the  JMCIS  segments  that  have 
been  created.  Some  segments  have  retained  the  name  of  the  original  system  from  which  the 
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functionality  evolved,  such  as  JOTS.  Other  segments  consist  of  various  functionality 
required  for  specific  missions  or  analytical  techniques  not  available  within  the  Unified 
Build  software.  New  functionality  is  added  to  the  base  JMCIS  functionality  by  creation  of 
a  new  JMCIS  segment. 


JMCIS 

Variants 


JMCIS 

Superset 


JOTS  Unified 

Applications  Build  Core 


Amphib 

Applications 


Strike  Aids  NIPS 


Segments  Environment  I  Transportation  Cryptologic  Intel 

_  _ _ _  Segments 


Figure  13:  JMCIS  Superset  Structure  [Ref.  25] 


NATO  ASWTDAcl  Air  Tasking  Briefing 

Applications  _  Order  Support 


d.  JMCIS  Variant 

A  variant  is  a  subset  collection  of  segments,  from  the  JMCIS  Superset, 
installed  for  a  specific  mission  area  such  as  mission  planning  or  battle  group  databa.se 
management.  Figure  13  also  shows  example  variants,  such  as  a  Joint  Task  Force  (JTF)  or 
the  aircraft  carrier  (CV)  variant.  The  boxes  labeled  as  JMCIS  segments  are  plug-in 
customization  modules  which  define  the  JMCIS  variant  and  control  what  access  an  operator 
has  to  services  provided  by  the  core.  These  are  in  effect  what  actually  define  the  system 
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and  distinguish  one  JMCIS  variant  from  another.  The  collection  of  various  JMCIS 
segments  are  simply  customized  modules  that  define  the  JMCIS  variant.  [Ref.  23:p.  2-8] 

3.  System  Hardware  Components 

The  JMCIS  software  described  above  is  currently  supported  by  two  hardware 

platforms,  the  DTC-II  SUN-based  systems  and  the  TAC-3  Hewlitt-Packard-based  systems 
in  a  client/server  configuration.  Although  these  are  presently  the  only  two  platforms 
supported  for  testing  and  configuration  management  purposes,  the  JMCIS  software  has 
been  successfully  ported  to  other  vendor-hardware  platforms  including  the  use  of  PCs  with 
appropriate  COTS  software  configurations  such  as  X-terminals.  The  JMCIS  software,  as 
delivered,  is  capable  of  supporting  the  standard  components  shown  below: 


TABLE  6:  STANDARD  JMCIS  HARDWARE  CONFIGURATIONS 

[Ref.  23:p.  2-13] 


TAC-3 

Standard  Components 

DTC-II 

Standard  Components 

HP-730  CPU 

4/300  or  4/1 10  SUN  CPU 

32  MB  RAM 

32  MB  RAM 

1.2  Gigabyte  Disk  Drive 

500  MB  Hard  Disk 

G1  Graphics  Card 

CG6  Graphics  Card 

19”  Color  Monitor 

19”  Color  Monitor 

Trackball/Mouse 

Trackball/Mouse 

Keyboard 

Keyboard 

Tape  Drive 

Tape  Drive 

4.  Objectives  of  the  JMCIS  Architecture 


While  examining  the  evolution  of  the  JMCIS  concept  and  system  architecture, 
there  are  a  number  of  objectives  which  become  apparent.  The  objectives  include  technical 
considerations  such  as  software  reusability,  enforcement  of  common  "look  and  feel",  and 
standardization  of  interfaces.  These  technical  objectives  provide  the  potential  for  significant 
cost  savings  and  further  development  acceleration.  The  objectives  include: 

•  Commonality  -  Developing  a  common  core  of  software  that  will  fonn  the 
foundation  for  Navy  and  Joint  systems. 

•  Reusability  -  Developing  a  common  core  of  software  that  is  highly  reusable  to 
leverage  the  investment  already  made  in  software  development. 

•  Standardization  -  Reducing  program  development  costs  through  the  commonality 
and  reusability  objectives  and  through  adherence  to  industry  standards.  This 
includes  the  use  of  commercially  available  software  components  whenever 
possible. 

•  Engineering  Base  -  Through  standardization  and  an  open  JMCIS  architecture, 
establishing  a  large  base  of  trained  software  and  systems  engineers. 

•  Training  -  Reducing  operator  training  costs  through  enforcement  of  a  uniform, 
human-machine  interface,  commonality  of  training  documentation,  and  a 
consistent  "look  and  feel.” 

•  Interoperability  -  Solving  the  interoperability  problem  (at  least  partially)  through 
common  software  and  consistent  system  operation. 

•  Certification  -  Providing  a  base  of  certified  software  so  that  systems  performing 
identical  functions  will  give  identical  answers. 
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•  Testing  -  Increasing  the  amount  of  common,  reusable  software  to  reduce  testing 
costs  since  common  software  can  be  tested  and  validated  once  and  then  applied 
to  many  programs. 

[Ref.  23:p.  1-13] 

D.  ONI  ARCHITECTURE  DEVELOPMENT 

As  the  US  Navy’s  lead  C4I  systems  development  agency,  the  Naval  Command, 
Control,  and  Ocean  Surveillance  Center  (NCCOSC),  Research,  Development,  Test,  and 
Evaluation  Division  (NRaD)  has  developed  a  Program  Management  Plan  (PMP)  for 
transitioning  ONI  systems  to  the  JMCIS  architecture.  The  architectural  approach  is 
intended  to  enhance  analyst  productivity  and  systems  functionality  while  maintaining  future 
IS  expenditures  within  fiscal  boundaries.  This  approach  will  support  ONI’s  vision  of 
providing  maritime  intelligence  to  consumers  and  afford  the  greatest  degree  of  compatibility 
with  C4I  systems  converging  under  the  JMCIS  and  GCCS  architectures.  JMCIS  software 
currently  provides  the  core  command  and  control  (C2)  system  capabilities  for  GCCS. 
JMCIS  also  provides  the  overall  C4I  architecture  for  the  Ocean  Surveillance  Information 
System  (OSIS)  Evolutionary  Development  (OED)  effort  which  will  provide  an  integrated 
intelligence  analysis  capability  at  the  Joint  IntelUgence  Centers  (JIC).  [Ref  26:p.  1] 

The  NRaD  plan  calls  for  transitioning  ONI  legacy  systems  to  standardized  hardware 
and  software,  and  developing  any  new  functionality  within  the  JMCIS  architecture.  The 
heart  of  this  effort  is  the  integration  of  ONI  systems  fimctionality  into  new  Intelligence 
Segments  within  the  JMCIS  architecture.  Additionally,  the  plan  calls  for  the  consohdation 
of  existing  maritime  databases  into  a  centrahzed  system.  This  section  will  describe  the 
target  JMCIS  architecture  that  will  incorporate  ONI  intelhgence  systems  and  databases. 
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1.  JMCIS  Intelligence  Segments 

The  target  architecture  envisioned  by  NRaD  for  ONI  systems  includes  integration 
of  current  systems  functionality  into  JMCIS  Intelligence  Segments  and  will,  therefore, 
consist  primarily  of  new  intelligence  segment  development.  The  functionality  of  the 
following  ONI  intelligence  systems  and  applications,  previously  described  in  the  baseline 
characterization,  will  be  incorporated  into  the  JMCIS  segments; 

•  Automated  Merchant  Identification  Ship  System  (AMIDSHIPS) 

•  Collection  Requirements  Management  Application  (CRMA) 

•  Joint  Maritime  Information  Element  (JMIE) 

•  Merchant  Watch  (MerWatch) 

•  SeaView 

•  SeaWatch  HI 

Additionally,  the  functionality  of  two  systems  that  are  managed  by  ONI  that  currently 
support  other  intelligence  sites  will  be  added  to  the  following  JMCIS  Intelligence 
Segments: 

•  Ocean  Surveillance  Information  System  (OSIS)  Baseline  Upgrade  / 

OBU  Evolutionary  Development  (OBU/OED) 

•  Joint  Deployable  Intelligence  Support  System  (JDISS) 

TJie  functions  of  the  JMCIS  Intelligence  Segments  will  include  analytical  tools  that 
currently  exist  within  the  SeaWatch  III  system,  the  SeaView  system’s  data  manipulation 
and  presentation  functions,  and  civil  maritime  analysis  functions  derived  from  the 
requirements  of  the  MerWatch  system  not  already  available  in  other  JMCIS  segments.  The 
additional  functionality  from  SeaWatch  III,  SeaView,  and  MerWatch  will  complement 
current  JMCIS  2.1  intelligence  segments  that  include  the  functionality  of  CRMA  and 
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JDISS.  The  OED  system  functions  operating  in  the  multi-level  secure  (MLS)  environment 
will  also  constitute  a  future  JMCIS  segment  [PMP]  The  initial  baseline  for  the  JMCIS 
intelligence  segments  will  be  the  JMCIS  2.1  software  which  includes  the  COE.  The 
baseline  will  consist  of  the  Unified  Build  (UB)  segment  and  the  other  JMCIS  2.1  optional 
segments.  [Ref.  26:pp.  2-3] 

The  JMCIS  configuration  for  ONI  intelligence  analysis  will  consist  of  the  following 
software  segments  with  functionality  summarized: 


a.  Unified  Build  (UB)  Segment 


Chart-2  Mapping 

Executive  Menu  Service 

Track  Database  Manager 

External  Communications 

Alert  Services 

Applications  Toolkit 

User  Interface  Toolkit 

Printer  Utilities 

b.  Civil  Maritime  Analysis  Segment  (CM AS) 


MerWatch  Release  C.l  Functions 

Maritime  Transportation  Model 

JMLE  Functions 

Link  Analysis 

SeaWatch  IB  Functions 

Access  to  Maritime  Databases 

Organization  Module  and  DB  Process 

Slide  Preparation 

Spread  Sheet 

Graphic  Drawing 

Report  Generation 

Maritime  Data  Alerts 

Optical  Character  Reader 

I 
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c.  Data  Visualization  Tools  (DVT)  Segment 


Data  Listing 

Iconify-by 

Color-by 

Count-by 

Histogram 

Scattergram 

Operations  Clock 

Get  Data  (Database  Retrieval) 

Format  Specification 

d.  JMCIS  Expedited  Text  Search  (JETS)  Segment 


Document  Search 

B1  Level  Security  Tags 

Narrative/Formatted  Message  Search 

Word  Processing  Tools 

Pre-Loaded  High  Use  Documents 

CD-ROM  Interface 

e.  Database  Browser  Segment 

Generic  RDBMS  Database  Scan 

/.  Additional  Intelligence  Segments 

JMCIS  segments  for  the  CRMA  and  JDISS  systems  are  being  developed 
separately.  The  functionality  of  these  segments  will  be  available  to  ONI  intelligence 
analysts  as  optional  segments  that  can  be  loaded  with  the  baseline  JMCIS  intelligence 
segments.  [Ref.  26:pp.  4-7] 

2.  Database  Segment  Development 

As  previously  discussed,  the  NRaD  plan  calls  for  the  consolidation  of  existing 
ONI  maritime  databases  into  a  centralized  system.  This  database  conversion  effort  will 
constitute  the  development  of  the  National  Maritime  InteUigence  Database  (NMID)  within 
the  JMCIS  architecture.  The  NMID  will  then  be  accessible  by  JMCIS  segments  including 
the  newly  created  Intelligence  Segments  for  ONI  analyst  use.  The  current  JMCIS  Central 
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Data  Base  Server  (CDBS)  for  afloat  systems  shall  incorporate  the  NMID  database  design 
and  structure  as  appropriate.  ONI  baseline  system  databases  to  be  consolidated  into  the 
NMID  include: 

*  SeaWatch  in  Database 

•  Merchant  Ship  Characteristics  (MSC)  Database 

♦  Naval  Intelligence  Database  (NID) 

♦  Joint  Maritime  Information  Element  (JMIE)  Database 

•  AMIDSHIPS  Imagery  Database. 

[Ref.  26:p.  7] 

3.  Technology  View 

The  JMCIS  development  and  integration  process  supports  both  the  SUN  DTC-2 

and  Hewlitt-Packard  (HP)  TAC-3  family  of  computers  and  peripherals  in  a  client/server 
configuration.  Figure  14  shows  a  generic  view  of  the  JMCIS  network  configuration  using 
the  TAC-3  and  DTC-2  platforms  with  access  available  to  PCs.  The  NRaD  plan  calls  for  the 
re-use  of  existing  ONI  hardware  in  the  target  architecture.  The  overall  design  calls  for  a 
distributed  architecture  of  server  systems  permitting  the  addition  of  other  servers  and 
transparent  distribution  of  database  tables.  Existing  JMCIS  database  management 
(Relational  Data  Base  Management  System  -  RDBMS)  software  permits  the  automated 
routing  of  database  queries  across  a  network  and  the  construction  of  a  composite  retrieval 
report.  [Ref.  27] 
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JMCIS  CONFIGURATION 


JMCIS  JMCIS 

WORKSTATION  WORKSTATION 


Figure  14:  ONI’s  JMCIS  Configuration 


a.  Re-use  of  PCs  as  X-Windows  Database  Clients 

Currently,  ONI  intelligence  analysts  use  386/486  PCs  as  data  entry 
terminals  for  inputing  NID  data  into  the  VAX  Oracle  database.  With  the  conversion  of  the 
VAX  to  a  UNIX  database  system,  continued  use  of  PCs  would  be  cost-effective  and 
provide  access  to  Windows  and  DOS  tools  and  applications  such  as  spreadsheets  and  word 
processors.  The  technical  approach  recommended  is  to  obtain  a  high  enough  performance 
COTS  package  to  allow  the  PCs  to  operate  as  X-terminals  which  access  the  UNIX  database 
system.  This  would  allow  fuU  database  edit  and  browse  functions  to  be  made  available  to 
all  PC  analysts.  [Ref.  27] 
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b.  Re-use  of  SUN  41690  Servers 


GOTS  high  speed  text  search  software  and  indexed  reference  and  analysts 
documents  would  be  hosted  on  these  servers.  These  systems  are  oriented  to  server 
functions  and  with  large  capacity  disks  would  be  a  cost  effective  storage  and  search 
system.  [Ref.  27] 

c.  Re-use  of  ONI  SUN  Sparc  2J10  Workstations 

These  client  workstations  would  be  able  to  perform  all  data  base  queries  to 
the  SeaWatch  III  server,  display,  and  manipulate  JMCIS  maps  and  tracks,  and  perform 
high  speed  text  search  retrievals  from  SUN  and  HP  servers.  [Ref.  27] 
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VI.  OPPORTUNITY  IDENTIFICATION 


A.  INTRODUCTION 

The  TAFIM  SBA  Planning  Guide  describes  opportunity  identification  as  the  phase 
.  .  where  projects  necessary  to  move  the  organization  from  its  current  environment  to  its 
target  environment  are  identified.”  This  phase  defines  the  “opportunity  vision”  for  the 
organization.  Specific  categories  for  evaluating  implementation  “payoff’  opportunities  are 
offered  by  the  SBA  Planning  guide.  These  categories  are  the  specific  objectives  for  the 
DoD  TAFIM  and  include: 

•  Improving  user  productivity 

•  Improving  development  efficiency 

•  Improving  portability  and  scalability 

•  Improving  interoperability 

•  Improving  vendor  independence 

•  Reducing  life-cycle  costs 

The  key  deliverable  of  this  phase  is  a  high-level  understanding  of  the  opportunities  at  hand. 
The  . .  entire  objective  is  to  describe  the  nature  of  the  target  architecture  opportunities 
and  the  role  they  will  play  in  closing  the  gap  between  the  baseline  environment  and  the 
target  architecture.”  [Ref.  7:Vol.  4,p.  5-5,6] 

B.  DESCRIPTION  OF  PROJECT  OPPORTUNITIES 
1.  User  Productivity 

To  the  end  user,  JMCIS  represents  a  information  system  which  is  distributed 
across  a  network  of  workstations.  System  operators  are  able  to  access  all  required 
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functionality  from  any  workstation,  regardless  of  the  individual  workstations  physical 
location  or  the  actual  location  where  the  processing  is  taking  place.  The  user  is  presented 
with  only  the  functionality  needed  to  meet  their  mission  with  other  unneeded  functionality 
hidden  to  prevent  overwhelming  the  user.  An  operator  with  a  different  set  of  tasks  is 
presented  with  a  different  set  of  functionality,  but  both  operators  perceive  that  the  system 
looks  and  operates  in  the  same  way.  JMCIS  will  appear  to  the  operators  as  the  identical 
information  system  in  use  by  other  military  commands  and  intelligence  centers  with 
completely  different  mission  objectives.  This  commonality  is  of  increasing  importance 
with  the  expanded  role  of  the  services  in  joint  operations.  [Ref.  23 :p.  1-7] 

Operator  training  is  simplified  by  conformance  to  identical  standards.  Training 
issues  are  significant  because  an  operator  may  be  expected  to  have  to  use  multiple  systems 
which  behave  completely  differently,  are  equally  complex  with  their  own  subtleties,  and 
which  give  slightly  different  answers.  Operator  turnover  is  rapidly  reaching  the  point 
where  the  time  it  takes  to  train  an  operator  is  a  significant  portion  of  the  time  the  operator  is 
assigned  to  his  current  tour  of  duty.  With  the  JMCIS  system  being  deployed  and  delivered 
to  both  the  afloat  and  ashore  user  communities,  a  commonality  between  sites  will  greatly 
reduce  the  training  required.  Through  the  use  of  an  open  architecture  and  standardization 
of  user  interfaces,  both  operator  and  maintenance  personnel  familiarization  with  a  single 
system  will  translate  directly  to  other  systems  using  similar  hardware  and  software 
environments. 

2.  Development  Efficiency 

From  the  perspective  of  a  system  program  manager,  JMCIS  presents  the 
opportunity  for  a  program  that  encompasses  several  programs.  With  the  impact  of 
decreasing  DoD  budgets,  program  managers  can  maintain  program  viability  and  achieve 
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considerable  savings  by  constructing  their  system  within  the  JMCIS  architecture.  Within 
the  current  budget  constraints,  these  potential  savings  appear  as  the  only  feasible  option  for 
many  programs.  [Ref.  23:p.l-7] 

The  greatest  opportunity  afforded  by  JMCIS  for  program  managers  may  be  the 
reuse  of  existing  and  proven  software.  Rather  than  concentrating  scarce  development 
resources  on  recreating  building  blocks,  the  resources  can  be  more  appropriately  applied  to 
customization  and  development  of  functionality  that  is  not  currently  available,  allowing  the 
focus  of  attention  on  mission  uniqueness. 

From  the  perspective  of  a  system  developer,  JMCIS  is  an  open  architecture  and  a 
software  development  environment  that  offers  a  collection  of  services  and  already  built 
modules.  The  system  developer’s  task  is  to  assemble  and  customize  the  existing 
components  from  JMCIS  while  developing  only  those  capabilities  unique  to  a  particular 
mission  requirement.  In  many  cases,  this  will  amount  to  adding  new  “pull-down”  menu 
entries.  The  JMCIS  developers  provide  detailed  instructions  on  how  to  make  applications 
or  systems  compliant  with  the  JMCIS  architecture.  These  instructions  include  details  on 
the  standard  user  interface  and  the  procedures  for  using  core  functionality  via  APIs.  The 
core  functionality  has  been  previously  developed  and  tested,  and  the  developer  need  only 
produce  segments  that  are  unique  in  functionality  to  their  particular  application  or  mission 
area.  The  JMCIS  COE  establishes  standards  and  provides  baseline  functionality  so  that  the 
system  developer's  task  is  to  extend  this  baseline  and  add  supplemental  functionality  to 
meet  mission  specific  requirements.  [Ref.  23;p.  1-7] 

3.  Portability  and  Scalability 

When  delivered  to  operational  sites,  the  JMCIS  software  is  installed  on 
workstations  that  may  be  grouped  together  by  mission  area  into  physical  spaces  or  other 
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logical  arrangements.  Within  a  space,  software  will  be  installed  on  one  or  more 
workstations,  depending  on  the  JMCIS  variant.  The  same  software  tapes  can  be  used  to 
load  any  workstation  regardless  of  the  site  or  location  of  the  workstation  in  the  space. 
During  the  installation  process,  only  that  portion  of  the  JMCIS  Superset  required  for  a 
particular  workstation  is  actually  loaded  onto  the  workstation.  From  a  general 
configuration  management  perspective,  only  one  set  of  tapes  are  required  to  be  controlled. 
The  same  set  of  software  tapes  can  be  use  throughout  the  site.  From  an  installation 
perspective,  the  site  installer  doesn’t  need  to  worry  about  different  tapes  to  load  on  different 
workstations  depending  upon  function.  Functionality  of  each  workstation  can  be  tailored 
to  that  workstation.  From  a  system  design  perspective,  the  ability  to  create  JMCIS  variants 
allows  the  flexibility  of  loading  and  executing  only  that  software  which  is  required  to 
support  a  mission  requirement.  [Ref.  23  :p.  1-22] 

Designed  to  be  hardware  independent,  the  JMCIS  the  software  successfully 
operates  on  a  variety  of  Silicon  Graphics,  HP,  Sun,  DEC,  and  PC  platforms.  It  can 
generally  run  on  any  hardware  system  which  supports  UNIX  System  V,  X-Windows,  and 
Motif.  While  JMCIS  has  been  installed  on  a  variety  of  platforms  with  a  wide  range  of 
platforms  used  in  its  development,  it  is  thoroughly  tested  only  for  DTC-II  and  TAC-3 
configurations  and  is  thus  formally  supported  only  for  these  two  computer  platforms.  [Ref 
23:p.  7-4] 

JMCIS  is  designed  as  a  client/server  architecture  so  that  core  processes  may  be 
distributed  across  a  LAN  or  run  on  a  single  workstation.  Thus,  JMCIS  is  scaleable  from  a 
single  workstation  up  to  a  network  of  workstations.  The  largest  JMCIS  installation  to  date 
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is  approximately  35  workstations  supporting  approximately  50  simultaneous  operators. 
Some  workstations  have  multiple  keyboards  and  monitors  to  support  more  than  one  user. 

[Ref.  23:p.  7-3] 

4.  Interoperability 

The  principle  advantage  of  the  JMCIS  architecture  is  that  participating 
communities  and  organizations  will  be  interoperable  because  they  use  exactly  the  same 
software  base.  With  the  JMCIS  approach,  not  only  is  the  same  software  used  by 
participating  communities  as  building  blocks,  but  the  same  system  (JMCIS)  is  deployed  to 
participating  communities.  The  JMCIS  philosophy  realizes  that  interoperability  problems 
are  usually  caused  by  differing  or  incorrect  interpretations  of  standards.  For  this  reason, 
the  JMCIS  architecture  calls  for  the  use  of  identical  software  to  perform  common  functions. 
The  primary  goal  of  JMCIS  is  to  have  a  body  of  C4I  software  that  can  be  configured  to 
support  a  variety  of  requirements  while  assuring  interoperability  among  sites.  The  JMCIS 
architecture  is  being  deployed  throughout  the  joint  command  and  tactical  communities  and 
will  serve  as  the  basis  for  future  command  and  control  systems  migrating  to  the  Global 
Command  and  Control  System  (GCCS). 

As  expressed  in  the  Joint  Staff’s  C4Ifor  the  Warrior,  the  ability  to  pull 
information  from  any  location  at  any  time  gives  the  Warrior  both  more  flexibility  and  the 
skill  to  tailor  information  to  his  specific  needs.  JMCIS  offers  the  Warrior  the  ability  to  pull 
information  from  external  sources.  The  Track  Database  Management  (TDBM)  system  is 
possibly  the  most  important  piece  of  the  JMCIS  system.  The  TDBM,  coupled  with  the 
extensive  communications  capabilities  of  JMCIS,  allows  greater  interoperability  with 
external  sources  and  databases.  The  TDBM  provides  standard  procedures  and  formats  to 
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add,  delete,  modify,  and  merge  basic  track  data  among  the  various  workstations  on  the 
local  area  networks.  [Ref.  23  ;p.  2-22] 

5.  Vendor  Independence 

One  of  the  objectives  of  JMCIS  is  to  avoid  having  command  and  control  systems 
tied  to  a  specific  hardware  platform  or  proprietary  system.  The  system  is  designed  to  be 
easily  transported  from  one  version  of  TAG  computer  to  the  next  with  the  capability  of 
exploiting  the  improved  capability  of  the  now  upgraded  system.  TAG  hardware,  GOTS 
and  GOTS  software,  and  both  government  and  industry  standards,  are  to  be  used  for  all 
current  and  future  JMGIS  development.  With  the  open  architecture  and  commercial 
standards  used  by  JMGIS,  advances  in  computing  platforms  can  be  easily  incorporated  by 
simply  changing  the  system’s  host  machine. 

The  JMGIS  software  is  also  not  vendor  proprietary  except  for  the  GOTS 
products  such  as  UNIX,  X-Windows,  and  Motif,  which  are  required  for  the  JMGIS 
environment.  These  GOTS  products  are  proprietary  implementations  of  industry 
standards.  All  other  software  has  been  developed  under  contract  to  the  US  Navy.  The 
government  retains  distribution  rights  for  the  government-funded  software  and  data.  [Ref. 
23:p.  7-3] 

The  financial  savings  of  moving  toward  an  open  architecture  environment  are 
also  significant.  While  hardware  costs  have  experienced  a  steady  downward  trend  over  the 
last  several  years,  costs  for  proprietary  software  have  greatly  increased.  The  use  of  GOTS 
software  products  counters  the  problem  of  increasing  costs  by  allowing  the  developer  of  a 
product  to  spread  the  cost  of  development  among  all  users  of  the  product.  Achieving  these 
economies  of  scale  is  the  major  cost  saving  characteristic  of  the  JMGIS  open  architecture 
environment. 
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The  commercial  marketplace  moves  at  a  faster  pace  than  the  government  or  DoD 
marketplace  and  advancements  are  generally  available  at  a  faster  rate.  Figure  15  presents 

the  dramatic  increase  in  performance  between  successive  TAC  system  procurements.  Use 

of  commercial  products  has  the  advantage  of  lowering  cost  by  using  already  developed  and 
produced  items,  increases  the  probability  of  product  enhancements  because  the  marketplace 
is  larger,  and  increases  the  probability  of  standardization. 


Figure  15:  Platform  Performance  Improvements  [Ref.  32] 


Technological  gains  occur  rapidly  in  the  computer  industry.  The  commercial 
computer  industry  introduces  new  systems  and  new  capabilities  approximately  every  1 8 
months.  With  the  average  DoD  major  automated  information  system  acquisition  taking 
over  24  months  from  requirements  specification  to  system  delivery,  DoD  is  constantly 


delivered  obsolete  systems.  However,  open  systems  architectures  can  offer  a  solution  to 
this  technological  dilemma.  The  basis  of  open  systems  are  the  common  development 
standards  from  which  products  can  be  developed  using  nonproprietary  specifications.  The 
advantages  of  using  an  open  systems  architecture  to  an  organization  the  size  of  DoD  present 
the  most  efficient  and  practical  approach  to  the  use  of  hardware  and  software. 

6.  Life-Cycle  Costs 

With  JMQS,  the  system  life-cycle  cost  is  reduced  by  development  and 
maintenance  of  a  single  system.  The  US  Navy  has  traditionally  funded  development  and 
redevelopment  of  the  same  functionality  across  systems.  Redevelopment  is  frequently 
necessary  because  of  technological  changes  as  algorithms  are  improved  or  as  hardware 
becomes  faster.  However,  much  of  the  development  cost  is  due  to  a  change  in  who  the 
developer  is  as  contracts  expire,  or  lack  of  coordination  between  programs  that  share 
common  requirements. 

Significant  savings  can  also  be  achieved  by  supporting  a  reduced  number  of  lines 
of  code.  This  reduction  in  lines  of  code  is  accomplished  by  implementing  a  common  core 
of  software  and  only  producing  the  unique  portions  of  the  JMCIS  segments.  Initial 
analysis  of  candidate  command  and  control  systems  eligible  for  migration  to  JMCIS  has 
revealed  significant  reductions  in  post-deployment  software  support.  A  study  conducted 
jointly  in  1993  by  NRaD  and  the  Marine  Corps  Tactical  Systems  Support  Activity 
(MCTSSA)  revealed  significant  redundancy  in  software  among  Marine  Corps  command 
and  control  (C2)  systems.  The  study  found  that  when  compared  to  a  common  core  of 
software,  such  as  that  existing  in  the  JMCIS/GCCS  Common  Core,  these  C2  system  could 
achieve  a  reduction  of  45  to  84  percent  in  software  lines  of  code. 
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Figure  16  the  shows  potential  reduction  in  source  lines  of  code  that  could  be 
achieved  in  an  air  defense  system  and  an  intelligence  analysis  system  if  they  were  converted 
to  software  segments  on  top  of  a  common  core  of  software.  The  MCTSSA  study  found 
that  the  vast  majority,  over  70  percent,  of  code  in  these  systems  was  used  for  Computer 
Software  Configuration  Items  (CSQ)  such  as  mapping/overlays,  track  management, 
message  processing,  communications  processing,  security,  and  system  administration. 
Each  system  studied  had  its  own  separate  software  to  support  these  common  functions. 
[Ref.  28] 


Figure  16:  Example  of  Software  Reduction  Using  a  Common  Core 


[Ref.  28] 

C.  OPPORTUNITIES  FOR  ONI 

The  project  opportunities  presented  in  the  previous  section  outline  the  potential 
benefits  to  DoD  offered  by  the  JMCIS  architecture  and  its  established  development 
procedures.  As  outlined,  the  opportunities  presented  are  directly  aligned  with  the 
objectives  of  the  DoD  TAFIM.  Likewise,  the  objectives  of  the  JMCIS  architecture  conform 
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with  ONI’s  IT  Principles  as  outlined  in  Chapter  ni.  This  section  will  specifically  address 
the  JMCIS  project  opportunities  with  regard  the  potential  benefit  to  ONI  addressing  each  IT 
Principle.  In  doing  so,  this  analysis  will  attempt  to  further  link  the  target  architecture  to  the 
strategic  vision  of  ONI. 

1.  Meta-Principles 

a.  Implement  a  demand-pull  capability  for  ONFs  intelligence 
dissemination. 

Integration  of  ONI  systems  with  the  joint  command  and  tactical  communities 
is  an  essential  step  toward  achieving  the  goal  of  a  demand-pull  dissemination  capability. 
While  migration  toward  the  JMCIS  architecture  does  not  in  itself  provide  the  demand-pull 
capability,  it  provides  the  critical  connectivity  to  the  operational  consumer  required. 

Further  development  of  ONI  systems,  products,  and  services  will  be  required  to  fully 
achieve  the  objectives  of  this  IT  Principle.  The  JMCIS  architecture  provides  the  means  to 
implement  a  demand-pull  capability  for  ONI’s  intelligence  dissemination. 

b.  All  ONI  systems  development  will  remain  consistent  with  DoD- 
wide  strategic  IS  initiatives. 

The  JMCIS  architecture  and  its  development  procedures  are  consistent  with 
DoD-wide  strategic  IS  initiatives.  Migration  to  the  JMCIS  architecture  and  the  participating 
defense  community  ensures  that  ONI  systems  will  conform  to  the  standards  of  the  CIM 
initiative.  Initiatives  such  as  the  Copernicus  architecture  emphasize  the  concept  of  demand- 
pull  data  services.  JMCIS  is  an  evaluation  of  Navy  C4I  systems  toward  the  achievement  of 
the  Global  Command  and  Control  System  (GCCS)  described  in  the  Joint  Staff’s  C4I for 
the  Warrior  initiative.  Migration  of  ONI  system  to  the  JMCIS  architecture  ensures  ONI 
systems  development  will  remain  consistent  with  DoD-wide  strategic  IS  initiatives. 
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c.  All  ONI  systems  development  will  be  accomplished  in  strict 
adherence  with  the  JMCIS  architecture  and  its  established 
systems  development  procedures. 

Adherence  with  the  JMCIS  architecture  and  its  established  systems 
development  procedures  will  enable  ONI  to  provide  maritime  intelligence  to  a  broad 
consumer  base  while  affording  the  greatest  degree  of  compatibility  with  Navy  C4I  systems 
converging  under  the  JMCIS  and  GCCS  architectures. 

d.  All  ONI  systems  development  will  be  in  consonance  with 
DODIIS  and  TAFIM  guidelines. 

DoD-wide  of  C4I  systems  have  undergone  analysis  in  a  migration  system 
selection  process  as  directed  by  the  Assistant  Secretary  of  Defense  (C3I).  The  migration 
systems  will  form  the  foundation  for  future  C41  architectures  and  are  in  consonance  with 
DODIIS  and  TAFIM  standards.  JMCIS  has  been  identified  as  the  primary  migration 
system  for  Navy  C2.  Migration  of  systems  to  the  JMCIS  architecture  ensures  ONI 
systems  development  will  remain  consistent  with  DODIIS  and  TAFIM  guidelines. 

2.  Information  Management 

a.  Create  the  National  Maritime  Intelligence  Database  (NMID). 

TTie  consolidation  of  current  ONI  databases  into  the  JMCIS  architecture  as  a 
data  segment  will  constitute  the  initial  implementation  of  the  NMID  concept  as  envisioned 
in  the  ONI  Strategic  Plan.  The  NMID  is  intended  to  provide  on-line  query  re.sponse 
services  to  the  consumer.s.  The  JMCIS  architecture  provides  the  essential  on-line 
connectivity  required  to  a  broad  range  of  consumers.  The  integration  with  the  user  / 
customer  has  been  identified  as  the  key  to  .success  for  the  NMID. 
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3.  Application  Management 


a.  Systems  architecture  development  must  retain  the  unique 

analytical  functionality  that  current  applications  provide  to  ONI 
intelligence  analysts. 

The  JMCIS  architecture  calls  for  the  integration  of  system  functionality 
through  the  development  of  JMCIS  soft\vare  segments.  Unique  analytical  functionality  that 
does  not  exist  in  current  JMCIS  components  must  be  integrated  into  a  JMCIS  software 
segment.  The  functionality  of  ONI  systems  are  planned  for  integration  into  a  range  of 
JMCIS  Intelligence  Segments. 

4.  Technology  Management 

a.  ONI  systems  will  migrate  to  an  open  systems,  client/server 
environment. 

JMCIS  is  designed  as  a  client/server  architecture  so  that  core  processes  may 
be  distributed  across  a  LAN  or  run  on  a  single  workstation.  JMCIS  also  offers  an  open 
systems  architecture  for  which  products  can  be  developed  using  nonproprietary 
specifications.  Migration  of  ONI  system  to  the  JMCIS  architecture  is  in  line  with  progress 
toward  migration  of  ONI  systems  to  an  open  systems,  client/server  environment. 

D.  SUMMARY  ASSESSMENT 

This  chapter  has  presented  an  analysis  of  the  opportunities  presented  by  the  JMCIS 
architecture  in  terms  potential  benefits  both  to  the  defense  community  and  the  strategic 
goals  of  ONI.  As  outlined,  the  opportunities  presented  by  the  JMCIS  architecture  and 
development  procedures  are  directly  in-line  with  the  objectives  of  the  DoD  TAFIM.  The 
JMCIS  architecture  provides  an  effective  opportunity  to  keep  pace  with  technological 
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advancements  while  implementing  open  systems  architectures  and  ensuring  standardization 
of  software  and  hardware  for  C4I  systems  among  the  services.  The  JMCIS  approach  to 
systems  development  addresses  many  recurring  problems  relative  to  procurement  and 
development  of  DoD  systems.  It  presents  many  opportunities  to  achieve  the  IS  objectives 
of  the  DoD  TAFIM  whUe  conforming  to  the  IT  Principles  of  ONI. 

A  summary  of  ONl’s  IT  Principles  and  the  opportunities  offered  by  the  JMCIS 
architecture  is  presented  in  Table  7.  In  addition  to  the  opportunities  offered  by  the  JMCIS 
architecture  and  its  development  procedures  to  the  defense  community  as  a  whole,  JMCIS 
provides  the  opportunity  to  achieve  many  of  the  strategic  objectives  of  ONI.  Table  7 
identifies  two  areas  where  significant  progress  toward  ONl’s  strategic  vision  can  be 
accomplished  through  migration  to  the  JMCIS  architecture.  JMCIS  offers  the  essential 
connectivity  with  the  consumer  that  is  a  critical  first  step  toward  achieving  a  demand-pull 
dissemination  capability.  This  connectivity  coupled  with  the  further  consolidation  of  ONI 
databases  into  a  centralized  data  segment  within  the  JMCIS  structure  will  be  a  significant 
step  toward  achieving  the  goal  of  providing  the  intelligence  consumer  with  an  on-line  query 
response  capability  as  envisioned  for  the  National  Maritime  Intelligence  Database  (NMID). 


TABLE  7:  OPPORTUNITIES  OFFERED  BY  JMCIS  ARCHITECTURE 


ONl’s  IT  PRINCIPLES 

JMCIS  OPPORTUNITY 

Implement  Demand-Pull  Dissemination 

Progress  Toward 

Remain  Consistent  with  DoD  Strategic  Initiatives 

YES 

Adhere  to  JMCIS  Architecture  Development  Procedures 

YES 

Remain  Consistent  with  DODIIS  and  TAFIM  Guidelines 

YES 

Create  the  NMID 

Progress  Toward 

Retain  Unique  Analytical  Functionality 

9 

Open  Systems,  ClientlServer  Environment 

YES 
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The  basic  idea  of  DoD  and  Navy  standardization  on  a  common,  open  systems 
architecture  certainly  makes  sense.  The  effective  migration  of  ONI  system  to  the  JMCIS 
architecture,  however,  will  be  a  significant  challenge.  Again  referring  to  Table  7,  the 
challenge  in  the  process  of  transitioning  ONI  systems  to  the  JMCIS  architecture  will  be 
ensuring  that  the  unique  analytical  functionality  currently  supporting  ONI  intelligence 
analysts  will  be  retained  in  the  newly  created  JMCIS  Intelligence  Segments.  While  ONI 
can  leverage  the  benefits  of  the  well  established  pool  of  software  segments  and  core 
services  offered  by  the  JMCIS  architecture,  careful  consideration  should  be  given  to  the 
risk  associated  with  potential  loss  of  functionality  in  the  transition  to  the  JMCIS 
architecture. 
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VII.  MIGRATION  ANALYSIS 


A.  INTRODUCTION 

This  phase  in  the  TAFIM  SBA  Planning  process  and  the  final  phase  presented  by  this 
thesis  will  address  the  migration  effort  required  to  move  an  organization  to  a  new  or  target 
architecture.  Because  most  migration  plans  deal  with  migrating  a  current  system  or  group 
of  systems  to  a  new  system  or  target  environment,  a  framework  is  needed  to  allow  decision 
makers  and  system  developers  to  evaluate  the  migration  path  selected.  The  procurement  of 
an  extensive  information  system  or  a  complex  upgrade  to  an  existing  system,  as  proposed 
for  ONI,  is  an  expensive  and  often  risky  proposition.  A  bad  decision  now  could  be  very 
costly  in  terms  of  both  expenditures  and  jeopardized  critical  mission  functions.  As  the 
TAFIM  SBA  Planning  Guide  suggests,  “Many  worthwhile  projects  have  floundered 
because  migration  was  not  adequately  scoped  prior  to  adoption.”  [Ref.  7:Vol.  4,p.  V-1] 
Therefore,  a  thorough  understanding  of  the  risk  is  required  and  an  effective  evaluation 
framework  is  needed. 

ONI’s  JMCIS  architecture  development  effort  involves  a  complex  sequence  of 
functionality  migration  and  capability  upgrades  toward  the  target  architecture  described  in 
Chapter  V.  Central  to  this  effort  is  the  creation  of  JMCIS  Intelligence  Segments  that  will 
incorporate  the  functionality  of  current  ONI  systems  and  offer  the  opportunity  to  add 
functionality  as  required.  The  JMCIS  Common  Operating  Environment  (COE) 
documentation  offers  a  high-level  “concept  of  operations”  for  integrating  new  functionality 
into  a  JMCIS  segment.  The  suggested  perspective  for  development  is  to  consider  JMCIS 
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as  a  baseline  collection  of  software  which  must  be  customized  and  supplemented.  The 
objective  is  to  build  on  top  of  JMCIS,  not  to  decompose  JMCIS  into  constituent  parts  and 
then  build  on  top  of  some  other  architecture  or  body  of  software.  Given  this  perspective, 
JMCIS  should  first  be  examined  to  determine  which  components  satisfy  the  requirements 
as  is,  which  need  customization,  which  need  extending,  and  what  functionality  is  totally 
missing  in  JMCIS.  The  JMCIS  COE  documentation  specifically  recommends  creating  a 
matrix  of  required  functionality  and  to  check  off  the  items  as,  performed  by  JMCIS, 
requires  modification,  or  new  functionality.  This  represents  the  initial  development  work 
that  must  be  performed.  [Ref.  23  :p.  1-24] 

This  chapter  is  intended  to  present  decision  makers  and  system  developers  with  a 
method  for  evaluating  a  complex  migration  effort  such  as  that  proposed  for  ONI.  The 
chapter  begins  by  defining  many  of  the  terms  required  to  properly  discuss  and  further 
analyze  a  migration  plan.  With  appropriate  terminology  as  a  backdrop,  this  chapter  then 
specifically  addresses  some  concerns  regarding  the  ONI  migration.  Finally,  this  chapter 
offers  a  suggested  framework  to  properly  evaluate  and  select  a  migration  path.  The 
fi-amework  focuses  on  maximizing  value  with  an  emphasis  on  functionality  when  scoping 
the  migration  problem.  Example  functionality/capability  matrices  are  presented.  This 
framework  could  be  used  for  further  analysis  of  migration  alternatives  that  may  be 
presented  to  ONT  as  the  transition  to  the  JMCIS  architecture  progresses.  The  framework  is 
presented  to  offer  decision  makers  a  structured  approach  to  evaluating  migrations  options. 
Further  cost/benefit  analysis  will  be  required  to  make  the  best  use  of  this  framework. 


B.  MIGRATION  TERMINOLOGY 


1.  System  Functionality 

System  functionality  is  determined  by  the  set  of  functions  that  are  automated  in  a 
current  system  or  desired  for  automation  in  a  target  system.  A  description  of  system 
functionality  can  often  be  found  in  a  System  Requirements  Specifications  document,  such 
as  exists  for  ONI’s  MerWatch  system.  The  system  functionality  can  be  displayed  in  a 
functionality/capability  matrix. 


FUNCTIONALITY  /  CAPABILITY  MATRIX 
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Figure  17:  Functionality  /  Capability  Matrix 

[Ref.  29:p.  42] 


2.  Technological  Capabilities 

In  order  to  provide  automated  support  to  the  set  of  required  system  functions,  a 
system  must  offer  a  set  of  capabilities  referred  to  as  technological  capabilities,  such  as  data 
retrieval  and  chart  displays.  For  example,  to  automate  the  data  manipulation  and  fusion 
functions  for  the  MerWatch  system,  data  retrieval  capabilities  such  as  query  interface. 


120 


execution,  and  results  are  just  a  few  of  the  technological  capabilities  required.  The 
technological  capabilities  will  also  be  displayed  in  a  functionality/capability  matrix.  Figure 
17  shows  an  example  functionality/capability  matrix  used  for  comparison  purposes  so  that 
the  relationship  between  them  can  be  clearly  seen.  For  example,  referring  to  Figure  17,  in 
order  to  automate  function  FI,  technological  capabilities  TCI  and  TC3  are  required.  [Ref. 
29:pp.  41-42] 

3.  Current  or  Base  System 

A  current  or  base  system  is  one  that  is  currently  in  use  or  one  that  could  be 
bought  in  the  near  term.  It  usually  automates  at  least  some  key  business  functions.  The 
current  system’s  functionality  is  typically  the  basis  for  determining  the  functions  and 
capabilities  of  the  target  system.  The  MerWatch  system  would  be  considered  a  base  system 
as  it  currently  exists. 

4.  Target  System 

A  target  system  is  one  that  will  provide  the  desired  level  of  automated  support 
with  the  desired  functionality  at  some  future  time.  The  target  system’s  capabilities  are  the 
technological  capabilities  required  to  provide  the  automated  support.  The  JMCIS  system 
with  the  desired  target  functionality  of  the  planned  Intelligence  Segments  is  considered  a 
target  system. 

5.  Migration  Path 

A  migration  path  is  an  incremental  series  of  upgrades  to  a  base  system  that 
eventually  leads  to  a  fully  functional  target  system.  A  viable  migration  path  is  one  that  is 
reasonable  in  terms  of  cost  and  risk  and  is  acceptable  to  the  operational  and  technical 
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experts  as  well  as  program  management  Figure  18  illustrates  how  a  base  system  could 
take  a  different  path  toward  achieving  the  required  target  system’s  capabilities.  [Ref.  29;p. 


43] 


6.  Migratory  System 

A  migratory  system  is  a  future  upgraded  version  of  a  particular  base  system  and 
usually  consists  of  the  base  system  plus  some  additional  technological  capabilities.  Several 
different  migratory  systems  could  be  derived  from  a  particular  base  system  given  different 
migration  paths.  The  JMCIS  system  with  less  than  the  desired  target  functionality  of  the 
planned  Intelligence  Segments  could  be  considered  a  migratory  system  for  ONI  at  any  time 
in  the  migration  process  prior  to  reaching  the  required  target  system  capability.  [Ref.  29;p. 
43] 
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7.  Value 


The  term  value  will  be  used  in  the  discussion  of  the  migration  framework  to 
characterize  the  benefit  gained  when  a  particular  function  is  provided  the  required  level  of 
automated  support.  The  added  value  or  benefit  to  the  intelligence  analysis  process  because 
of  the  automation  of  a  function  could  be  measured  in  terms  of  a  relative  importance  or 
weight.  In  either  case,  a  value  or  benefit  to  the  analysis  as  a  whole  can  be  associated  with  a 
target  system’s  function.  Values  are  discounted  to  their  equivalent  present  values  using  a 
discount  rate.  Discounting  converts  future  values  to  their  equivalent  present  values.  The 
framework  will  use  the  prescribed  DoD  discount  rate  of  ten  percent  throughout  the 
analysis.  [Ref.  29:p.  44] 

The  term  expected  value  will  be  used  in  the  discussion  when  comparing  decision 
alternatives.  In  many  decision-making  situations  it  is  possible  to  obtain  probability 
estimates  for  the  possible  outcomes,  referred  to  as  states  of  nature.  The  framework  will 
consider  various  scenarios  that  have  different  outcomes.  The  expected  value  approach  to 
decision-making  evaluates  each  decision  alternative  in  terms  of  its  expected  value.  The 
expected  value  of  a  scenario  is  the  value  of  its  outcome  adjusted  for  the  probability  of  the 
scenario  occurring. 

8.  Cost 

The  term  cost  will  be  used  in  the  discussion  of  the  migration  framework  to 
characterize  the  cost  of  adding  technological  capabilities  to  the  base  system  along  a 
migration  path  toward  the  target  system.  The  framework  will  focus  on  the  cost  associated 
with  a  particular  technological  capability  and  its  integration  into  an  migratory  system. 

Costs  could  include  both  initial  conversion  costs  and  life-cycle  operating  costs. 
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The  cost  of  adding  technological  capabilities  in  different  time  periods  can  be 
aggregated  by  discounting  the  costs  to  a  common  point  in  time.  All  costs  can  then  be 
expressed  in  terms  of  the  present  using  a  discount  factor.  Discounting  converts  future 
costs  into  their  equivalent  present  costs  using  a  discount  rate. 

C.  MIGRATION  RISKS 
1.  Technical  Concerns 

The  process  of  properly  assessing  risk  requires  an  examination  of  the  migration 
plan  from  a  technical  perspective.  A  strategically  sound  project  does  not  necessarily  mean 
that  technical  criteria  are  being  fulfilled.  Proposed  questions  that  should  be  answered  when 
evaluating  any  systems  migration  effort  include: 

•  Is  the  proposed  technical  solution  for  migration  practical? 

•  Will  the  proposed  migration  path  meet  all  of  the  current  or  desired  performance 
needs? 

Qualifying  a  solution  as  practical  should  require  testing  the  proposed  solution  against  a 
track  record  of  technological  performance.  For  example,  the  query  response  time  for  a 
current  system  such  as  SeaWatch  ID  should  be  compared  to  that  of  the  proposed  migratory 
system.  A  practical  system  implies  that  it  is  achievable.  The  complexity  of  operations  in  a 
client/server  environment  must  be  considered.  A  proposed  migration  path  may  not  be 
practical  if  there  is  not  adequate  expertise  or  time  available  to  develop  and  implement  the 
proposed  solution.  [Ref.  20:p.  65] 
a.  Schedule 

The  NRaD  plan  for  migrating  ONI  systems  to  the  JMCIS  architecture  calls 
for  the  development  and  implementation  of  the  JMCIS  Intelligence  and  Database  Segments 
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to  support  ONI  analysts  by  mid- 1995.  This  schedule  appears  somewhat  fast-paced  given 
the  unproven  ability  of  the  proposed  distributed  system  to  meet  ONI  requirements.  For 
example,  the  SeaWatch  IE  system  contains  approximately  500,000  lines  of  code,  largely 
dependent  on  the  IBM  mainframe.  The  bulk  of  this  code  is  not  portable  to  a  UNIX-based 
platform  and  must  be  redeveloped.  Furthermore,  the  SeaWatch  IE  database  is  several 
gigabytes  in  size,  and  so  attempting  to  replace  a  system  of  this  size  in  as  little  as  one  year 
risks  the  loss  of  both  functionality  and  system  reliability.  [Ref.  30] 

b.  System  Performance 

Performance  of  the  migratory  system  is  a  second  potentially  high-risk  area. 
Query  response  time  needs  to  be  thoroughly  evaluated  for  the  proposed  migratory  system. 
Moving  the  large  SeaWatch  IE  system  to  the  TAC-3  distributed  environment  requires 
realistic  testing  under  workloads  that  are  representative  of  the  conditions  that  the  system  is 
likely  to  encounter  when  implemented.  As  previously  discussed,  throughput  capabilities 
remain  a  major  strength  of  the  mainframe.  The  mainframe  has  been  optimized  to  support 
high  volume  and  complex  data  management  with  the  ability  to  manage  multiple  complex 
tasks.  The  most  advanced  and  developed  desktop  systems  are  just  beginning  to  compete 
with  the  mainframe  in  this  area. 

c.  Database  Sizing 

The  issue  of  properly  sizing  the  database  servers  to  replace  the  mainframes 
is  another  area  of  concern.  Whether  the  single  processor  TAC-3  server  is  capable  of 
replacing  an  IBM  mainframe  seems  to  require  a  more  thorough  analysis.  Testing  may 
determine  that  a  multiprocessor  configuration  will  be  required  to  achieve  the  requirements 
of  the  SeaWatch  IE  base  system.  If  so,  a  more  realistic  set  of  cost  figures  may  be  needed 
for  decision  makers  to  accurately  evaluate  the  migration  plan.  This  technical  decision 
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should  be  supported  with  a  thorough  analysis  of  the  Sea  Watch  III  workload,  a  realistic  set 
of  performance  tests,  and  a  careful  examination  and  costing  of  candidate  database  servers. 
Testing  should  support  approximately  25  users  simultaneously  to  determine  how  a  fully- 
loaded  SeaWatch  in  replacement  system  will  perform.  [Ref.  30] 

d.  System  Functionality 

As  the  COE  documentation  describes,  integrating  new  functionality  into 
JMCIS  is  conceptually  straightforward.  One  of  the  first  steps  is  the  process  of  creating  a 
checklist  of  required  functionality.  The  checklist  is  used  to  note  what  capabilities  from 
JMCIS  meet  the  known  functional  requirements,  what  components  from  JMCIS  need 
further  customization,  and  what  new  functionality  must  be  developed.  However,  this  step 
has  proven  to  be  easier  said  than  done.  Determining  the  functionality  of  JMCIS  or  any  new 
system  can  be  a  challenging  task  for  a  systems  developer.  The  size  and  scope  of  the  ONI 
migration  effort  with  the  numerous  applications  and  varying  degrees  of  documented  system 
requirements  only  serves  to  further  complicate  this  process.  The  migration  framework 
presented  in  this  chapter  offers  an  approach  to  evaluate,  based  on  functionality,  migration 
path  alternatives  that  should  be  considered  for  further  analysis. 

2.  Cost  Concerns 

Proper  migration  evaluation  should  include  a  cost/benefit  analysis  to  summarize 
the  estimated  cost  associated  with  the  migration  plan  in  sufficient  detail  to  give  decision 
makers  the  ability  to  decide  whether  or  not  to  proceed  with  the  process.  As  the  previous 
discussion  on  technical  concerns  highlighted,  many  of  the  technical  risks  can  have  further 
cost  affects.  With  the  technical  feasibility  thoroughly  examined,  the  tangible  costs  of 
conversion  to  and  operations  in  the  target  environment  must  be  considered.  [Ref  2():p.  79] 
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a.  Conversion  Costs 


Cost/Benefit  analysis  must  include  conversion  costs  and  costs  of  operating 
in  the  new  environment.  Often  the  costs  associated  with  conversion  are  overshadowed  by 
promises  of  cost  savings  in  a  new  environment.  Up-front  conversion  costs  to  distributed 
systems  can  represent  a  sizable  investment.  Initial  estimates  indicate  the  initial  conversion 
of  current  ONI  functionality  into  the  JMCIS  Intelligence  Segments  will  cost  over  $3.5 
million.  [Ref.  26:p.  1 1] 

b.  Operating  Costs 

Estimating  costs  of  distributed  systems  requires  looking  at  the  significant 
overhead  costs  that  accompany  networked  architectures.  In  general,  mainframe-based 
systems  can  be  classified  as  capital  intensive,  whereas  the  distributed  environment  is 
labelled  as  more  labor  intensive.  Initial  estimates  indicate  that  life-cycle  costs  for  the 
JMCIS  environment  at  ONI  will  be  approximately  $640,000  per  year.  It  should  be  noted 
that  costs  of  operating  in  a  distributed  environment  are  often  grossly  underestimated. 
Personnel  support  and  systems  management  costs  should  be  thoroughly  evaluated  to 
prevent  distorted  cost  estimates.  Alternative  cost  estimates  may  be  required. 

[Ref.  26:p.  12] 

D.  A  FRAMEWORK  FOR  MIGRATION  EVALUATION 

1.  The  Need  for  Effective  Evaluation 

This  section  will  present  a  framework  for  evaluating  migration  path  alternatives 
based  on  a  theoretical  structure.  The  structure  for  this  framework  is  based  on  research 
presented  by  Captain  Daniel  Egge,  USMC,  in  his  thesis  entitled,  “A  Framework  for 
Evaluating  Evolutionary  Upgrade  Paths  of  Command,  Control,  and  Communications 
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Systems.”  His  framework  was  used  to  evaluate  the  upgrade  path  for  the  Marine  Corps’ 
Tactical  Combat  Operations  (TCO)  System  with  NTCS-A  serving  as  the  target  system. 

The  stmcture  of  his  framework  has  been  slighdy  modified  to  specifically  address  migration 
path  evaluation.  As  previously  discussed,  this  framework  could  be  used  for  further 
analysis  of  migration  alternatives  that  may  be  presented  to  ONI  as  the  transition  to  the 
JMCIS  architecture  progresses.  The  framework  is  presented  to  offer  decision  makers  a 
structured  approach  to  evaluating  the  migrations  options. 

One  of  the  most  difficult  aspects  of  evaluating  information  systems  is  that  they 
will  continually  change  over  time,  given  evolving  technologies,  standards,  and 
applications.  Very  few  frameworks  or  methodologies  exist  that  deal  specifically  with  the 
timing  of  migration  projects,  often  referred  to  as  the  temporal  component  of  information 
systems.  A  framework  is  needed  for  evaluating  the  migration  paths  with  specific  regard  for 
how  the  timing  aspect  of  the  migration  effort  will  affect  the  eventual  success  or  failure  of 
the  effort  as  a  whole. 

Most  C4I  system  procurements  today  can  be  viewed  as  upgrades  to  existing 
systems.  As  discussed,  the  evolution  of  Navy  C41  systems  has  been  a  continual  process  of 
upgrades  and  consolidation  of  functionality  from  previous  systems.  Even  large 
procurements  that  make  sweeping  changes  will  be  incremental  and  evolutionary. 

Therefore,  it  is  useful  to  develop  a  framework  for  comparing  alternative  migration  paths 
rather  than  alternative  static  information  systems.  As  the  path  alternatives  are  often 
distinguished  simply  by  the  temporal  component,  the  timing  of  the  change  should  be 
specifically  considered.  [Ref.  29:p.  37] 
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2.  Defining  the  Problem 

The  first  step  of  decision  making  is  to  identify  and  define  the  problem.  Large- 

scale  software  development  typically  involves  cost,  performance,  schedule,  and  other  risk 
constraints.  Theoretical  stmctures  often  use  model  development  to  frame  the  problem.  A 
mathematical  model  for  the  ONI  migration  effort  could  be  expressed  as: 

Maximize:  Value 

Subject  to:  Costs  <  Budget 

This  mathematical  expression  describes  the  problem’s  objective  with  regard  for  the 
constraints.  The  model  clearly  states  the  migration  effort’s  objective  of  maximizing  value 
(functionality)  with  the  migration  path  chosen,  constrained  by  costs  that  have  some 
budgetary  limit.  With  the  problem  clearly  defined,  the  framework  for  addressing  the 
problem  can  now  be  presented. 

3.  Overview 

As  presented  with  the  discussion  of  Navy  C41  systems  evolution,  new 
information  systems  are  typically  procured  over  time,  employing  incremental  upgrades  to 
keep  pace  with  technology,  and  migrating  functionality  into  a  more  technologically  capable 
system.  This  temporal  component  of  information  systems  is  a  difficult  aspect  to  evaluate. 
Because  of  the  “time  value  of  money,”  any  economic  analysis  must  consider  not  only  how 
much  a  proposal  will  cost,  but  also  when  the  expenditures  wiU  be  made  and  then- 
discounted  values.  To  include  this  consideration  in  the  analysis,  each  alternative  migration 
path’s  life-cycle  costs  must  be  expressed  in  terms  of  their  present  value.  The  framework 
presented  will  focus  on  maintaining  functionality  while  emphasizing  the  temporal 
component  in  evaluating  the  migration  paths  toward  a  goal  or  target  system.  [Ref.  29:p.  39] 
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This  framework  presents  a  method  that  could  be  useful  to  the  decision  makers  in 
making  a  final  decision  or  in  evaluating  a  potential  migration  path.  The  framework  is 

heuristic  in  nature  and  should  be  viewed  as  a  simple  procedure  for  finding  a  set  of  feasible 

solutions  when  considering  alternative  migration  paths.  The  framework  contains  six 
primary  steps: 

1.  Define  the  target  system’s  functionality  and  required  technological  capabilities. 

2.  Develop  scenarios  where  the  system  wiU  be  used  to  the  end  of  the  planning 
horizon  and  then  define  a  representative  set  of  migration  paths  from  the  base  system  toward 
the  target  system  within  each  scenario;  each  path  then  becomes  a  viable  candidate  path. 

3.  Develop  the  discounted  (life-cycle)  cost  for  each  viable  candidate  path  and  identify 
a  set  of  candidate  paths  that  are  budget-feasible.  Discounting  converts  future  costs  into 
their  equivalent  present  costs  using  a  discount  rate. 

4.  Develop  the  discounted  value  of  each  budget-feasible  path  and  identify  a  set  of 
candidate  paths  that  have  the  greatest  value.  Values  are  discounted  into  their  equivalent 
present  values  using  a  discount  rate. 

5.  Determine  the  expected  value  of  each  of  the  remaining  candidate  paths  with  regard 
for  the  likelihood  of  occurrence  of  each  associated  scenario.  A  probability  estimate  for  each 
scenario  is  used  to  adjust  greatest  value  identified  in  step  four  and  determine  an  expected 
value  for  each  path. 

6.  Select  the  candidate  migration  path  with  the  greatest  expected  value. 

Figure  19  summarizes  the  steps  in  the  framework  and  will  be  used  in  the  subsequent 
discussion. 


130 


Viable  Migration  Paths 


Functionality/Capabilites 

& 

Values  of  Functions 


Budget-Feasible  Paths 


Migration  Path  Selected 

with  Greatest  Expected  Expected  Value  of  Paths  Paths  of  Greatest  Value 
V alue  subject  to  Cost 

Figure  19:  The  Steps  of  the  Framework 


The  first  step  of  the  framework  defines  the  target  system’s  functionality  in  terms 
of  the  technological  capabilities  required  to  automate  each  of  the  required  functions.  The 
value  of  each  function  is  also  determined  (value  will  be  further  discussed).  The  output  of 
this  step  is  a  table  showing  the  relationships  between  the  target  system’s  technological 
capabilities  and  the  functions  it  must  automate  along  with  the  value  of  each  function.  [Ref. 
29:p.  49] 

The  second  step  of  the  framework  begins  by  characterizing  the  base  system  in 
terms  of  the  technological  capabilities.  Various  scenarios  should  then  be  considered  with 
regard  for  future  changes  that  could  affect  the  migration  effort  during  the  planning  horizon. 
For  example,  potential  changes  in  the  functionality  requirements  and  technological 
capabilities,  as  well  as  future  budgetary  constraints  and  schedule  modifications,  should  be 
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considered.  A  representative  set  of  viable  paths  to  the  target  system  that  spawn  from  the 
base  system  is  then  determined  for  each  possible  scenario  considered  over  the  planning 

horizon.  The  output  of  this  step  is  a  depiction  of  viable  candidate  paths  associated  with 
each  scenario. 

The  third  step  of  the  framework  involves  assigning  capability-derived  costs  to 
each  viable  candidate  path  at  discrete  time  intervals.  These  costs  are  then  discounted  to  the 
present  to  determine  the  life-cycle  cost  of  each  viable  candidate  path.  Candidate  paths  that 
exceed  budgetary  constraints  are  then  discarded.  The  output  of  this  step  is  a  set  of  budget- 
feasible  candidate  paths  associated  with  each  scenario  developed  in  step  two  of  the 
framework  and  a  discounted  cost  determined  for  each  candidate  path. 

The  fourth  step  of  the  framework  involves  assigning  functionality-derived 
values  to  each  candidate  path  at  discrete  time  intervals.  These  values  are  then  discounted  to 
the  present.  The  candidate  paths  with  the  greatest  discounted  values  are  then  identified  for 
each  scenario.  The  output  of  this  step  is  a  set  of  candidate  paths  that  have  the  greatest 
discounted  values  associated  with  each  scenario.  Each  scenario  will  have  a  single  candidate 
path  of  greatest  discounted  value. 

The  fifth  step  of  the  framework  involves  consideration  for  the  likelihood  of 
occurrence  of  each  scenario  in  order  to  calculate  the  expected  value  of  the  remaining 
candidate  paths.  Probability  estimates  are  made  for  each  scenario.  The  output  of  this  step 
is  a  set  of  candidate  paths  that  have  expected  values  associated  with  each  scenario  based  on 
the  likelihood  of  occurrence. 

The  final  step  of  the  framework  involves  selecting  the  candidate  path  with  the 
greatest  expected  value.  This  should  result  in  the  identification  of  a  budget-feasible 
migration  path  that  provides  the  maximum  value. 
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4.  Discussion 


A  more  detailed  discussion  will  now  be  presented  to  provide  further  illustration 

of  the  framework.  The  discussion  will  provide  examples  to  show  application  of  the 
framework  to  the  ONI  migration  effort  where  possible.  Values  and  costs  used  in  examples 
are  not  actual  and  are  included  in  order  to  facilitate  discussion.  Furthermore,  only  a  small 
sample  of  functionality  and  technological  capabilities  will  be  used  in  the  discussion.  The 
intent  is  to  simply  discuss  a  framework  for  example  purposes  that  will  provide  assistance  to 
further  analysis. 

a.  Define  the  Target  System 

The  first  step  of  the  framework  begins  by  defining  the  target  system’s 
functionality  in  terms  the  technological  capabilities  required  to  automate  each  of  the  required 
functions.  Functions  that  require  automation  are  usually  those  functions  and  key  processes 
that  the  organization  must  perform  to  support  the  primary  mission.  Functional 
decompositions  are  often  useful  in  this  phase.  Figure  20  shows  a  generic  functional 
decomposition.  A  simple  decomposition  using  an  intelligence  system,  for  example,  might 
include  production  of  an  intelligence  report  as  the  function  FI.  This  function  could  be 
decomposed  into  many  lower-level  functions  represented  by  Fl.l,  FI. 2,  FI. 3,  and  so  on. 
Lower-level  fimctions  could  include  product  generation,  product  output,  and  office 
information  exchange  as  required  in  the  production  of  an  intelligence  report. 


133 


FUNCTIONAL  DECOMPOSITION 


Figure  20:  Generic  Functional  Decomposition  [Ref.  29:p.  49] 


Once  the  functions  are  identified,  the  technological  capabilities  required  to 
provide  the  automated  support  can  be  determined.  The  objective  is  to  obtain  a  list  of 
capabilities  required  to  automate  each  function.  Technological  capabilities  required  could 
include  text  editing,  display  controls,  and  LAN  connectivity,  for  example.  It  should  be 
realized  that  some  of  the  capabilities  identified  in  the  list  may  not  be  available  yet,  given  the 
current  state  of  technology.  A  functionality/capability  matrix  can  then  be  constructed  that 
shows  the  relationship  between  the  functions  and  the  technological  capabilities  as 
previously  discussed.  [Ref  29:p.  49] 

After  the  relationship  between  target  system  functionality  and  required 
capabilities  is  known,  the  value  of  each  of  the  functions  is  then  determined.  The  objective 
is  to  assign  a  value  or  weight  to  the  functions  based  on  the  benefit  added  to  the  analysis 
process  when  a  particular  function  is  automated.  One  method  to  accomplish  this  would  be 
to  elicit  relative  values  or  the  importance  of  each  function  from  experienced  operational 
experts  or  analysts.  The  objective  is  to  recognize  the  relative  importance  to  the  analytical 
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process  of  automating  each  target  system  function.  Various  methods  have  been  used  to 
elicit  these  weighted  values.  System  user  groups,  such  as  the  MerWatch  User  Group 
(MUG)  at  ONI,  can  be  used  to  define  the  value  of  individual  functions.  Methods  such  as 
the  Analytical  Hierarchy  Process  (AHP)  or  the  Simple  Multi-Attribute  Rating  Technique 
(SMART)  can  provide  tools  to  aid  in  obtaining  relative  value  or  weight  of  each  function.  It 
is  important  to  emphasize  that  the  value  should  be  estimated  from  the  user’s  perception  of 
the  relative  importance  of  a  function.  [Ref.  29:pp.  51-52] 
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Figure  21:  Functionality  /  Capability  Mlatrix  with 
Values  Added 


The  output  of  this  step  is  a  matrix  highlighting  the  relationships  between 
the  target  system’s  technological  capabilities  and  the  functions  it  must  automate  along  with 
the  value  of  each  function.  Figure  21  illustrates  the  a  fimctionality/c^pability  matrix  with 
the  added  VI,  V2, . . .  Vn  to  represent  the  value  of  that  particular  function.  This  matrix 
could  serve  as  a  valuable  means  of  assessing  the  development  effort  required  for  the 
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JMCIS  Intelligence  Segment  as  suggested  in  the  COE  documentation.  For  example,  the 
functions  of  the  Civil  Maritime  Analysis  Segment  could  be  compared  to  the  existing 
technological  capabilities  of  the  JMCIS  core  software.  Assigned  values  could  help 
prioritize  the  schedule  for  the  segment  development  effort. 

b.  Define  Candidate  Paths 

The  second  step  of  the  framework  begins  by  characterizing  the  base  system 
in  terms  of  the  technological  capabilities.  The  base  system  possesses  a  set  of  technological 
capabilities  that  will  be  added  incrementally  over  time  to  eventually  fulfill  the  technological 
requirements  of  the  target  system.  Several  viable  migration  paths  could  be  taken.  Each 
path  will  become  a  candidate  migration  path  and  could  be  developed  by  creating  a  specific- 
scenario  of  technological  change  and  automation  for  the  base  system.  As  technological 
capabilities  are  added  to  the  base  system,  migratory  systems  are  realized  until  finally  the 
capabilities  of  the  target  system  are  obtained.  [Ref.  29;pp.  54-55] 

The  migration  paths  developed  will  occur  over  some  planning  horizon, 
during  which  a  base  system  will  evolve  given  the  automation  opportunities  chosen. 

Various  scenarios  could  occur  over  this  planning  horizon  that  wiU  directly  impact  the 
migration  effort  and  the  automation  opportunities  available.  For  example,  potential  changes 
in  the  functionality  requirements  and  technological  capabilities  could  result  from  a  change  in 
mission  orientation  and  the  consumer’s  intelligence  needs.  Future  budgetary  constraints 
could  also  pose  a  greater  limitation  than  expected.  Schedule  modifications  should  also  be 
considered  with  particular  regard  for  the  availability  of  technology,  for  example.  Each 
scenario  foreseen  for  the  planning  horizon  will  have  a  representative  set  of  viable  paths  to 
the  target  system  that  spawn  from  the  base  system.  With  these  viable  paths  determined,  the 
output  of  this  step  is  a  depiction  of  viable  migration  paths  associated  with  each  scenario. 
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At  each  discrete  time,  a  viable  migration  path  will  have  associated  with  it  a  set  of 
technological  capabilities  that  have  been  incrementally  added.  Each  candidate  migration 
path  will  have  a  changing  list  of  technological  capabilities  and  a  changing  list  of  functions 
that  it  can  support  depending  on  the  discrete  time.  The  next  steps  in  the  framework  will 
determine  the  overall  costs  and  value  of  each  candidate  migration  path  taking  into  account 
these  changing  capabilities. 

c.  Develop  Life-Cycle  Costs 

The  third  step  in  the  framework  involves  assigning  capability-derived  costs 
to  each  viable  candidate  path  at  discrete  time  intervals.  These  costs  are  then  discounted  to 
the  present  to  determine  the  life-cycle  cost  of  each  viable  candidate  path.  The  primary 
objective  of  this  step  is  to  derive  a  single  overall  discounted  cost  for  each  candidate 
migration  path. 

Each  candidate  path  can  be  viewed  as  a  series  of  increments  that  adds 
technological  capabilities.  Figure  22  depicts  an  example  breakdown  of  a  candidate  path 
with  regard  for  the  time  at  which  a  function  is  automated.  The  distinction  between  paths  is 
that  some  can  provide  certain  capabilities  sooner  rather  than  several  years  in  the  future. 
Costs  used  in  this  framework  are  derived  from  capabilities  and  are  the  cost  of  adding  a 
particular  technological  capability  at  some  time  in  the  migration  path  evolution.  Costs 
should  include  the  costs  associated  with  research,  development,  testing,  and  evaluation 
(RDT&E);  procurement;  and  15  years  of  operation  and  support.  [Ref.  29:p.  60] 
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The  procedure  for  determining  the  overall  discounted  cost  of  a  candidate 
migration  path  involves  determining  when  the  path  will  succeed  in  automating  the  functions 
of  the  target  system.  Figure  23  provides  cost  determination  for  an  example  migration  path 
using  sample  estimated  cost  figures.  After  determining  the  discounted  costs  of  the 
technological  capabilities  (using  a  10  percent  discount  rate),  a  single  overall  discounted  cost 
for  each  path  can  be  determined.  Candidate  paths  that  exceed  budgetary  constraints  are 
then  discarded.  The  output  of  this  step  is  a  set  of  budget-feasible  candidate  paths 
associated  with  each  scenario  with  a  discounted  cost  determined  for  each  candidate  path. 
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Figure  23:  Cost  of  a  Candidate  Path  [Ref.  29:p.  79] 


d.  Develop  Value 

The  fourth  step  of  the  framework  involves  assigning  functionality-derived 
values  to  each  candidate  path  at  discrete  time  intervals.  These  values  are  then  discounted  to 
the  present.  The  primary  objective  of  this  step  is  to  derive  a  single  overall  discounted  value 
for  each  candidate  migration  path.  Since  the  value  of  each  function  has  been  previously 
determined,  the  overall  value  of  a  candidate  migration  path  depends  on  the  functions  it 
succeeds  in  automating  and  when  they  are  automated.  The  overall  value  of  a  candidate 
migration  path  is  derived  by  first  adding  the  values  of  the  functions  that  a  set  of  capabilities 
automates. 
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Figure  24:  Developing  Value  [Ref.  29;p.  56] 


A  previously  discussed,  each  candidate  path  can  be  viewed  as  a  series  of 
increments  that  adds  technological  capabilities.  Figure  24  depicts  an  example  breakdown 
of  a  candidate  path  with  regard  for  the  time  at  which  a  function  is  automated.  If  each 
candidate  path  receives  the  value  for  a  function  when  it  succeeds  in  automating  it,  all  paths 
will  eventually  receive  the  same  value  since  all  candidate  paths  eventually  will  reach  the 
capabilities  of  the  target  system.  Again,  one  of  the  distinctions  between  paths  is  that  some 
can  provide  certain  capabilities  sooner  rather  than  several  years  in  the  future.  Paths  could 
have  other  distinctions  related  to  the  particular  migration  path  scenario.  Other  scenarios 
could  include  consideration  for  changes  in  technology,  mission  orientation,  or  political 
climate.  Since  the  migration  effort  will  occur  over  some  period  of  time  with  regard  for 
these  various  scenarios,  a  method  of  discounting  the  value  of  added  functions  must  be 
used.  It  is  generally  agreed  that  the  sooner  a  system  can  automate  a  particular  function,  the 
more  valuable  that  system  will  be  to  the  user.  A  migration  path  that  automates  a  particular 
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function  earlier  should  receive  a  greater  value.  Therefore,  if  two  migration  paths  are  being 
compared,  the  path  that  automates  a  function  sooner,  will  receive  a  greater  value  than  a  path 
that  automates  the  function  later.  This  concept  of  functionality-based  value  can  provide  a 
means  of  prioritizing  the  important  technological  capabilities  for  migration  path  selection 
decisions.  [Ref.  29:p.  58-60] 

The  procedure  for  determining  the  overall  discounted  value  of  a  candidate 
migration  path  involves  determining  when  the  path  will  succeed  in  automating  the  functions 
of  the  target  system.  Figure  25  provides  value  determination  for  an  example  migration  path 
using  weighted  values.  In  this  example,  the  technological  capability  that  automates  the 
mapping  function  in  year  two  was  given  a  weighted  value  of  two.  The  overlay  was  given  a 
weighted  value  of  one.  After  determining  the  discounted  value  of  the  functions,  a  single 
overall  discounted  value  for  each  path  can  be  determined  (using  a  10  percent  discount  rate). 
The  candidate  paths  with  the  greatest  discounted  values  are  then  identified  for  each 
scenario.  The  output  of  this  step  is  a  set  of  candidate  paths  that  have  the  greatest 
discounted  values  associated  one-for-one  with  each  scenario. 
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Figure  25:  Value  of  a  Candidate  Path  [Ref.  29:p.  79] 


e.  Consider  Likelihood 

The  fifth  step  of  the  framework  involves  consideration  for  the  likelihood  of 
occurrence  of  each  scenario  in  order  to  calculate  the  expected  value  of  the  remaining 
candidate  paths.  Probability  estimates  are  made  for  each  scenario.  The  probability  estimate 
is  then  used  to  adjust  the  overall  discounted  value  of  each  candidate  path.  For  example,  if  a 
particular  scenario  has  a  90  percent  likelihood  of  occurrence,  then  the  overall  discounted 
value  for  the  candidate  path  of  greatest  value  associated  with  that  scenario  would  be 
multiplied  by  the  factor  .90.  This  step  results  in  an  expected  value  for  the  candidate  path 
derived  from  the  overall  discounted  value  of  that  path,  adjusted  for  the  likelihood  of 
occurrence  of  each  scenario.  The  output  of  this  step  is  a  set  of  candidate  paths  that  have 
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expected  values  associated  with  each  scenario  based  on  the  scenario’s  likelihood  of 
occurrence. 

/.  Select  Migration  Path 

The  final  step  of  the  framework  involves  selecting  the  candidate  path  with 
the  greatest  expected  value.  Each  scenario  will  now  have  associated  with  it  a  single  budget- 
feasible  migration  path  with  an  expected  value  based  on  the  likelihood  of  occurrence  of  that 
scenario.  Selection  is  based  on  the  candidate  path  with  the  greatest  expected  value.  This 
should  result  in  the  identification  of  a  budget-feasible  migration  path  that  provides  the 
maximum  value  to  the  analysts  subject  to  particular  constraints.  For  this  framework,  the 
path  that  maximizes  value  subject  to  cost  constraints  while  reaching  the  target  systems 
capabilities  is  the  “best”  path. 

E.  SUMMARY  AND  CONCLUSIONS 

The  size  and  scope  of  the  migration  effort  can  vary  significantly  according  to  several 
determinants.  The  organization’s  size,  culture,  and  complexity,  the  current  and  target 
architectures,  the  extent  of  the  change,  and  the  value  and  cost  of  the  technology  will  all 
determine  the  extent  of  migration  activity  required.  For  some  organizations,  the  migration 
activity  may  be  minor  and  may  not  need  to  be  supported  by  extensive  structure  and 
analysis.  For  others,  the  issues  of  migration  will  be  such  that,  after  analysis,  the  migration 
costs  and  issues  will  loom  large  enough  that  the  organization  will  determine  that  its  best 
strategy  is  to  delay  the  migration,  at  least  for  the  interim,  until  the  costs  become  less 
prohibitive.  [Ref.  7:Vol.  4,p.  V-7] 

This  chapter  presented  a  method  for  evaluating  a  complex  migration  effort  such  as 
that  proposed  for  ONI.  The  chapter  offers  a  suggested  framework  to  evaluate  and  select  a 
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migration  plan.  The  framework  focuses  on  maximizing  value  with  an  emphasis  on 
functionality  when  scoping  the  migration  problem.  This  framework  could  be  used  for 
further  analysis  of  migration  alternatives  that  may  be  presented  to  ONI  as  the  transition  to 
the  JMCIS  architecture  progresses.  Decision  makers  can  apply  the  structured  approach  of 
this  framework  to  evaluated  migrations  options.  Further  cost/benefit  analysis  will  be 
required  to  make  the  best  use  of  this  framework.  As  previously  presented,  “[I]t  is  difficult 
enough  merely  to  define-let  alone  measure-value  and  cost.  Despite  these  practical 
difficulties,  we  can  still  consider  various  ways  of  achieving  a  reasonable  balance  between 
value  and  cost.”  [Ref.  31:p.  1] 

Migration  analysis  requires  research  and  validation  of  the  elements  of  each  possible 
migration  solution.  The  TAFIM  Planning  Guide  offers  some  typical  questions  that  need  to 
be  asked  when  evaluating  a  migration  proposal: 

•  Is  it  viable? 

•  What  products  does  it  need?  On  what  standards  are  they  built? 

•  When  will  the  products  be  available? 

•  What  can  we  do  to  position  for  future  decisions? 

•  What  education  and  learning  must  be  undertaken? 

•  How  do  we  introduce  the  consequent  cultural  change?  What  is  the  cultural 
change  for  development  staff,  operational  staff,  users,  and  management? 

•  What  are  the  relative  costs  of  each  option? 

•  What  benefits  are  dehvered  by  the  option? 

[Ref  7:Vol.  4,p.  V-8] 
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VIIL  SUMMARY  AND  CONCLUSIONS 


This  thesis  has  been  written  primarily  for  top  and  middle  management  at  ONI  in  an 
effort  to  demonstrate  the  process  of  strategic  information  systems  planning.  Strategic 
information  systems  planning  aligns  an  organization’s  information  systems  with  its  critical 
strategic  goals  and  supporting  mission-specific  functions.  The  main  thrust  of  this  thesis 
demonstrates  the  application  of  established  principles  of  information  systems  planning  to 
the  architectural  development  effort  at  ONI.  By  examining  established  information  systems 
planning  practices,  architectural  design  methodologies.  Department  of  Defense  (DoD) 
guidelines,  and  published  ONI  organizational  objectives,  this  thesis  guides  the  reader 
through  the  decision-making  process  involved  in  strategic  IS  planning. 

The  thesis  presents  a  framework  for  developing  a  strategically  aligned  systems 
architecture  specifically  applicable  to  current  systems  development  efforts  at  ONI.  The 
methodology  is  structured  on  guidance  provided  by  the  DoD’s  Technical  Architecture 
Framework  for  Information  Management  (TAFIM)  Standards-Based  Architecture  (SBA) 
Planning  methodology.  The  thesis  demonstrates  the  validity  of  using  the  stmctured 
architectural  approach,  presented  by  the  TAFIM  and  other  strategic  IS  planning  concepts, 
in  concert  with  intelligence-specific  IS  planning  guidance,  provided  through  the  DoD 
Intelligence  Information  System  (DODIIS)  program,  to  systematically  address  the  issues, 
problems,  and  critical  decisions  faced  by  organizations  attempting  the  strategic  IS  planning 
process. 
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This  paper  was  conceived  and  written  to  assist  decision  makers  at  ONI  as  well  as 
systems  developers  at  NRaD.  It  provides  both  top-level  managers  (technical  and 
operational)  and  potential  users  (intelligence  analysts)  at  ONI  with  a  breadth  of 
understanding  about  the  Joint  Maritime  Command  Information  System  (JMCIS)  and  its 
role  in  supporting  the  strategic  vision  of  ONI,  the  potential  benefits  in  terms  of  improved 
products  and  services  for  ONI’s  intelligence  consumers,  and  the  overall  benefits  to  the 
defense  community.  Likewise,  it  offers  system  developers  insight  to  the  users’ 
requirements,  providing  the  perspective  of  the  intelligence  analysts  as  well  as  the  business 
needs  of  maritime  intelligence.  Hopefully,  this  thesis  provides  a  breadth  of  understanding 
that  can  serve  as  a  vehicle  for  communication,  coordination,  and  increased  understanding 
among  involved  parties. 

A.  STRATEGIC  IS  PLANNING 

This  thesis  demonstrates  a  structured  approach  to  strategic  information  systems  (IS) 
planning  that  provides  a  guide  for  developing  an  information  systems  strategy  and 
architecture  to  support  organizational  goals  outhned  in  the  ONI  Strategic  Plan.  Many 
companies  having  strategic  IS  planning  activities  agree  that  planning,  set  in  a  strategic 
framework,  allows  decision  making  today  that  better  prepares  them  for  the  future. 
Strategic  IS  planning  must  therefore  be  an  integral  part  of  an  organization’s  general 
planning  process  and  be  performed  within  this  strategic  framework.  [Ref.  3:p.  9] 

Strategic  IS  planning’s  basic  purpose  is  to  link  the  business  and  information 
strategies.  The  heart  of  this  effort  establishes  clear  IS  objectives  and  expresses  them 
through  the  organization’s  IT  Principles.  Establishing  proposed  IT  Principles  through  the 
analysis  of  ONI’s  strategic  objectives  served  to  initiate  the  architectural  development  effort 
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of  this  research  as  presented  earlier  in  Chapter  HI.  This  key  accomplishment  guided  the 
planning  effort  explicitly  linked  the  IT  Principles  with  the  opportunities  offered  by  the 
proposed  target  architecture  as  presented  in  Chapter  VI.  Ensuring  this  strategic  alignment 
serves  as  the  key  to  any  strategic  IS  planning  effort  and  remains  essential  to  the 
accomplishment  of  ONI’s  IT  Principles. 

B.  ARCHITECTURAL  OVERVIEW 

As  introduced  in  Chapter  H,  Pressure  Point  Analysis  (PPA)  offers  a  strategic  IS 
analysis  technique  providing  a  method  to  gather  and  present  information  focusing  on  issues 
of  particular  interest  to  management,  rather  than  on  the  specific  technical  problems. 

Pressure  Point  Analysis  provides  a  simphstically  clear  analytical  approach  for  planning 
embodied  in  four  fundamental  questions  concerning  the  role  of  IS  in  an  organization: 

•  Where  are  we? 

•  Why  should  we  change? 

•  What  could  we  do? 

•  What  should  we  do? 

The  display  of  answers  to  these  questions  provides  a  useful  overview  to  characterize  ONTs 
strategic  IS  planning  process.  Figure  24  uses  the  PPA  model  to  present  an  overview  of 
ONI’s  strategic  IS  planning  process  and  the  associated  pressures  using  the  PPA  model. 

The  following  discussion  utilizes  this  model  and  serves  as  a  review  of  the  structural 
approach  used  throughout  this  thesis. 
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Figure  24:  Strategic  Pressure  Point  Analysis  Chart  for  ONI 

[Ref.  3:p.  68] 
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1.  Where  are  we? 


Chapter  HI  initiated  the  structured  methodology  offered  by  the  architectural 
approach  to  strategic  IS  planning.  The  chapter  presents  the  issues  that  initiate  the  planning 
process  within  an  architectural  framework.  The  development  of  initial  ONI  IT  Principles 
guides  the  systems  development  and  architectural  planning  efforts  in  this  phase.  Finally, 
the  key  issues  that  impact  the  overall  architecture  process  are  presented  to  set  the  stage  for 
further  phases  in  the  planning  and  development  process. 

Chapter  IV  presented  a  high-level  baseline  characterization  of  the  IS  environment 
currently  supporting  the  critical  mission  /  business  functions  at  ONI.  Applications, 
systems,  and  databases  that  directly  support  ONI  intelligence  analysts  are  presented.  A 
management  view  of  the  organization  focuses  on  the  integration  of  information  and  the 
needs  of  the  organization.  The  inventory  activities  of  this  phase  provide  key  information 
for  migration  planning  based  on  the  valuation  of  existing  assets  and  the  identification  of 
risk. 

2.  Why  should  we  change? 

Chapter  HI  of  this  thesis  discusses  key  strategic  initiatives,  described  as 
“strategic  divers,”  that  have  provided  a  vision  for  information  management  within  DoD. 
These  initiatives  directly  influence  current  and  future  systems  development  efforts  within 
the  Navy  and  particularly  at  ONI.  Initiatives  such  as  the  Corporate  Information  Initiative 
(CIM)  and  C4Ifor  the  Warrior  present  the  common  theme  of  support  to  the  operational 
commander  through  an  integrated  strategic  information  management  infrastructure  and  the 
development  of  interoperable  C4I  systems  across  DoD.  Recent  C4I  systems  integration 
efforts  within  the  Navy  reflects  the  guidance  provided  by  these  initiatives. 
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Recent  DoD  systems  development  efforts  have  received  further  direction  in  order 
to  programmatically  achieve  the  goals  of  the  strategic  initiatives.  All  of  these  directives 
intend  to  guide  C4I  systems  development  in  this  era  of  declining  human  and  financial 
resources,  increasing  requirements,  and  resultant  compressing  schedules.  As  these 
directives  indicate,  program  managers  must  design,  develop,  procure,  and  support 
affordable  systems  necessary  to  meet  Naval  and  joint  C4I  requirements  in  view  of  these 
constraints.  Given  that  the  genesis  of  the  new  Global  Command  and  Control  System 
(GCCS)  is  the  Joint  Maritime  Command  Information  System  (JMCIS),  the  basis  now 
exists  to  implement  within  ONI  a  truly  interoperable,  open  systems,  C41  architecture  to 
support  national,  theater,  and  tactical  customers. 

3.  What  could  we  do? 

Chapter  V  presents  a  draft  target  architecture  to  guide  systems  development  and 
the  current  evolution  at  ONI.  The  chapter  specifically  presents  the  Joint  Maritime 
Command  Information  System  (JMCIS)  architecture.  A  thorough  understanding  of  the 
JMCIS  architecture  is  essential  to  the  architectural  development  efforts  at  ONI.  Selection  of 
a  target  architecture  must  take  into  account  the  issues  emerging  from  the  baseline  phase 
while  addressing  the  objectives  target  environment. 

Chapter  VI  builds  on  the  basic  understanding  of  the  target  architecture  by 
identifying  the  opportunities  presented  by  JMCIS.  The  opportunities  are  presented  with 
regard  to  the  strategic  goals  and  IT  Principles  of  ONI.  Opportunities  are  identified  which, 
once  implemented,  can  demonstrate  the  value  of  the  architecture  and  provide  immediate 
benefits  to  the  organization. 
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4.  What  should  we  do? 


Finally,  Chapter  VII  presents  a  framework  to  assist  decision-makers  in  the 
process  of  analyzing  a  migration  path  toward  the  target  architecture  environment.  This 
chapter  specifically  addresses  concerns  regarding  the  migration  plan  for  ONI  systems.  It 
offers  a  suggested  framework  for  evaluation  and  selection  a  migration  path.  The 
framework  offers  decision  makers  a  structured  approach  for  evaluating  various  migration 
options. 

C.  AREAS  FOR  FURTHER  RESEARCH 

1.  Alternative  Architectures 

The  stmctured  approach  of  this  thesis  follows  the  planning  process  presented  in 
DoD’s  TAFIM  SB  A  Planning  Guide.  Modifications  were  made  where  appropriate  to  fit  the 
process-specific  concerns  of  OKI’s  architectural  development  effort.  For  this  reason,  the 
JMCIS  architecture  was  presented  without  considering  alternative  infrastructures  and  was 
evaluated  as  the  optimum  choice.  A  more  typical  planning  process  should  examine  the 
question  of  “What  could  we  do?”  by  listing  strategic  alternatives  and  selecting  the  best 
approach.  The  target  architecture  development  phase  should  present  the  alternative 
approaches. 

2.  Alternative  Migration  Options 

Similarly,  the  evaluation  of  migration  requires  that  the  alternative  migration 
strategies  are  examined  to  determine  the  effort,  cost,  and  adequacy  of  the  approach.  This 
requires  research  and  validation  of  the  elements  of  each  possible  migration  solution.  With 
the  ONI  migration  effort,  alternative  migration  approaches  need  to  be  thoroughly  scoped. 
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Chapter  VII  offers  a  framework  to  assist  in  migration  option  selection.  For  example 
purposes,  migration  options  could  be  developed  to  evaluate  the  effects  of  implementing  the 
same  functionality  at  different  times  in  the  planning  horizon. 

3.  Cost/Benefit  Analysis 

As  suggested  in  Chapter  VII,  thorough  cost/benefit  analysis  should  be  performed 

before  committing  resources  to  new  IS  projects.  Furthermore,  a  basic  principle  of 
economic  analysis  is  to  investigate  all  reasonable  alternative  methods  of  satisfying  a  given 
objective.  When  considering  a  cost/benefit  analysis  of  information  systems,  the  absolute 
value  of  both  cuirent  and  future  expenditures  for  the  alternatives  must  be  considered. 
Because  of  the  “time  value  of  money,”  the  cost  of  each  proposed  solution  must  be 
evaluated  with  consideration  for  when  expenditures  will  be  made  and  express  each 
alternative’s  life-cycle  cost  in  terms  of  its  present  value. 

D.  FUTURE  STRATEGIC  IS  PLANNING  CONSIDERATIONS 

The  objective  of  strategic  IS  planning  is  to  define  the  explicit  connection  between  an 
organization's  business  plan  and  its  information  systems  plan.  Strategic  IS  planning  must 
therefore  be  an  integral  part  of  an  organization’s  general  planning  process  in  order  to 
support  the  organization's  goals  and  objectives. 

1.  Strategic  IS  Planning 

The  success  of  any  strategic  planning  process  requires  the  support  of  top 
management.  OKI’s  Strategic  Plan  offers  considerable  regard  for  the  role  of  information 
system  in  the  strategic  vision  of  the  organization.  Continued  top-level  support  is  crucial. 
Strategic  IS  planning  efforts  are  not  likely  to  succeed  without  a  vision  driven  from  the 
highest  levels  of  the  organization. 


152 


2.  The  Architectural  Approach 

Possibly  the  most  important  role  of  strategic  IS  planning  is  the  development  of  a 
systems  architecture  that  can  be  used  to  successfully  guide  the  organization  through  a 
potentially  difficult  migration.  Architecture  is  not  necessarily  a  diagram  of  the  components 
or  a  set  of  diagrams.  Rather,  it  is  a  set  of  strategically  aligned  policies  and  guidelines  that, 
when  followed,  should  lead  the  organization  to  the  desired  information  systems 
environment. 
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